March 15, 2014 Re: Final by default? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Iain Buclaw | On Friday, 14 March 2014 at 18:06:47 UTC, Iain Buclaw wrote:
> else version (OSX) {
> version (PPC)
> iSomeWackyFunction();
> else
> SomeWackyFunction(); // In hope there's no other Apple hardware.
There's also ARM, ARM64, x86 32bit and PPC64.
--
/Jacob Carlborg
|
March 15, 2014 Re: Final by default? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg Attachments:
| On 15 Mar 2014 09:44, "Jacob Carlborg" <doob@me.com> wrote: > > On Friday, 14 March 2014 at 18:06:47 UTC, Iain Buclaw wrote: > >> else version (OSX) { >> version (PPC) >> iSomeWackyFunction(); >> else >> SomeWackyFunction(); // In hope there's no other Apple hardware. > > > There's also ARM, ARM64, x86 32bit and PPC64. > > -- > /Jacob Carlborg Wonderful - so the OSX bindings in druntime are pretty much in a dia state for someone who wishes to port to a non-X86 architecture? I know the BSD and Solaris code needs fixing up and testing. |
March 15, 2014 Re: Final by default? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Daniel Murphy Attachments:
| On 15 March 2014 18:50, Daniel Murphy <yebbliesnospam@gmail.com> wrote: > "Walter Bright" wrote in message news:lg0vtc$2q94$1@digitalmars.com... > > > I find it peculiar to desire a 'final accessor'. After all, >> >> class C { >> int x; >> final int getX() { return x; } <= what the heck is this function >> for? >> } >> > > Yeah, it's stupid, but people do it all over the place anyway. Religiously. They're taught to do this in books and at university, deliberately. Seriously though, there are often reasons to put an interface in the way; you can change the implementation without affecting the interface at some later time, data can be compressed or stored in an internal format that is optimal for internal usage, or some useful properties can be implied rather than stored explicitly. Programmers (reasonably) expect they are inlined. For instance framesPerSecond() and timeDelta() are the reciprocal of eachother, only one needs to be stored. I also have very many instances of classes with accessors to provide user-facing access to packed internal data, which may require some minor bit-twiddling and casting to access. I don't think this is unusual, any programmer is likely to do this. empty(), length(), front(), etc are classic examples where it might not just return a variable directly. Operator overloads... >_< It's a major breaking change. It'll break nearly every D program out there >> that uses classes. >> > > This is nonsense. I tried out the warning on some of my projects, and they required ZERO changes - because it's a warning! > > Phobos requires 37 "virtual:"s to be added - or just change the makefile to use '-wi' instead of '-w'. Druntime needed 25. > > We don't even need to follow the usual 6-months per stage deprecation - We could leave it as a warning for 2 years if we wanted! > > Grepping for class declarations and sticking in "virtual:" is as trivial as a fix can possibly be. > My game that I'm hacking on at the moment has only 2 affected classes. The entire game is OO. Most virtuals are introduced by interfaces. So with that in mind, it's not even necessarily true that projects that use classes will be affected by this if they make use of interfaces (I certainly did at Remedy, exclusively). Phobos is a standard library, surely it's unacceptable for phobos calls to break the optimiser? Consider std.xml for instance; 100% certain to appear in hot data crunching loops. What can be done about this? It can't be fixed, because that's a breaking change. Shall we document that phobos classes should be avoided or factored outside of high frequency code, and hope people read it? |
March 15, 2014 Re: Final by default? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Manu | "Manu" <turkeyman@gmail.com> wrote in message news:mailman.133.1394879414.23258.digitalmars-d@puremagic.com... > Phobos is a standard library, surely it's unacceptable for phobos calls to break the optimiser? > Consider std.xml for instance; 100% certain to appear in hot data crunching loops. > What can be done about this? It can't be fixed, because that's a breaking change. Shall we > document that phobos classes should be avoided or factored outside of high frequency code, and > hope people read it? I think std.xml should be avoided for other reasons... |
March 15, 2014 Re: Final by default? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Daniel Murphy | On Saturday, 15 March 2014 at 08:50:00 UTC, Daniel Murphy wrote:
> This is nonsense. I tried out the warning on some of my projects, and they required ZERO changes - because it's a warning!
>
> Phobos requires 37 "virtual:"s to be added - or just change the makefile to use '-wi' instead of '-w'. Druntime needed 25.
>
> We don't even need to follow the usual 6-months per stage deprecation - We could leave it as a warning for 2 years if we wanted!
>
> Grepping for class declarations and sticking in "virtual:" is as trivial as a fix can possibly be.
When virtual keyword was introduced in Github master I immediately went to add a bunch of "virtual" in my projects... only to find myself done after few minutes.
I see some irony in the fact that if classes are made final-by-default, removing all the unnecessary "final" attributes would be an order of magnitude longer task.
|
March 15, 2014 Re: Final by default? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Daniel Murphy | Daniel Murphy:
> This is nonsense. I tried out the warning on some of my projects, and they required ZERO changes - because it's a warning!
>
> Phobos requires 37 "virtual:"s to be added - or just change the makefile to use '-wi' instead of '-w'. Druntime needed 25.
Andrei has decided to not introduce "final by default" because he thinks it's a too much large breaking change. So your real world data is an essential piece of information to perform an informed decision on this topic (so much essential that I think deciding before having such data is void decision). So are you willing to perform your analysis on some other real D code? Perhaps dub?
Bye,
bearophile
|
March 15, 2014 Re: Final by default? | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | > So are you willing to perform your analysis on some other real D code? Perhaps dub?
Or vibe?
Bye,
bearophile
|
March 15, 2014 Re: Final by default? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Manu | Am Fri, 14 Mar 2014 13:48:40 +1000 schrieb Manu <turkeyman@gmail.com>: > I feel like this was aimed at me, and I also feel it's unfair. > > If you recall back to the first threads on the topic, I was the absolute > minority, almost a lone voice. Practically nobody agreed, infact, there was > quite aggressive objection across the board, until much discussion about it > has passed. > I was amazed to see in this thread how many have changed their minds from > past discussions. Infact, my impression from this thread is that the change > now has almost unanimous support, and by my recollection, many(/most?) of > those people were initially against. > > To say this is a small vocal faction is unfair (unless you mean me > personally?). A whole bunch of people who were originally against, but were > convinced by argument and evidence is not a 'faction' with an agenda to > intimidate their will upon leadership. > I suspect what seems strange to the participants in this thread, that > despite what eventually appears to have concluded in almost unanimous > agreement (especially surprising considering the starting point years > back!), is the abrupt refusal. > That's Walter's prerogative I guess... if he feels that strongly about it, > then I'm not going to force the issue any more. > > I am surprised though, considering the level of support for the change > expressed in this thread, which came as a surprise to me; it's the highest > it's ever been... much greater than in prior discussions on the topic. > You always say forum participation is not a fair representation of the > community, but when the forum representation is near unanimous, you have to > begin to be able to make some assumptions about the wider communities > opinion. Me too, I got the impression, that once the library authoring issue was on the table, suddenly everyone could relate to final-by-default and the majority of the forum community found it to be a reasonable change. For once in a decade it seemed that one of the endless discussions reached a consensus and a plan of action: issue a warning, then deprecate. I was seriously relieved to see an indication of a working decision making process initiated by the forum community. After all digitalmars.D is for discussing the language. Then this process comes to a sudden halt, because Walter gets negative feedback about some unrelated braking change and Andrei considers final-by-default good, but too much of a breaking change for what it's worth. Period. After such a long community driven discussion about it. One message that this sends out is that a proposal, even with almost complete lack of opposition, an in-depth discussion, long term benefits and being in line with the language's goals can be turned down right when it is ready to be merged. The other message is that the community as per this forum is not representative of the target audience, so our decisions may not be in the best interest of D. Surprisingly though, most commercial adapters that ARE here except for one, have no problem with this announced language change for the better. I neither see a small vocal faction intimidating (wow!) the leadership, nor do I see a dictate of the majority. At least 2 people mentioned different reasons for final-by-default that convinced most of us that it positively changes D. ...without threats like "we won't use D any more if you don't agree". Paying customers including Facebook can have influence on what is worked on, but D has become a community effort and freezing the language for the sake of creating a stable target for them while core language features are still to be finalized (i.e. shared, allocation) is not convincing. -- Marco |
March 15, 2014 Re: Final by default? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Daniel Kozák | On Sat, 15 Mar 2014 04:08:51 -0400, Daniel Kozák <kozzi11@gmail.com> wrote:
> deadalnix píše v Pá 14. 03. 2014 v 22:25 +0000:
>> On Friday, 14 March 2014 at 22:06:13 UTC, Daniel Kozák wrote:
>> > First I think have something like
>> >
>> > @disable(final,nothrow) would be the best way, but than I think
>> > about it
>> > and realize that final(false) is much more better.
>> >
>>
>> If I may, final!false . We have a syntax for compile time
>> parameter. Let's be consistent for once.
>>
>> The concept is solid and is the way to go. DIP anyone ?
>
> final!true
> final!(true)
> final(!true) oops :)
If final!true is valid, final(true) and final(!true) will not be.
-Steve
|
March 15, 2014 Re: Final by default? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Paulo Pinto | Am Fri, 14 Mar 2014 19:29:27 +0100 schrieb Paulo Pinto <pjmlp@progtools.org>: > That is why the best approach is to have one module per platform specific code, with a common interface defined in .di file. Which is basically what Iain proposed for druntime. Then the thread got hijacked and talked about three different issues in the end. Walter answered to the other issues, but not to Iain's original request, Andrei agreed with Walter, the discussion ended, pull request closed and nothing will happen ;-) https://github.com/D-Programming-Language/druntime/pull/731 https://github.com/D-Programming-Language/druntime/pull/732 I think we'll have to revisit this at some point, but right now there's other stuff to be done... |
Copyright © 1999-2021 by the D Language Foundation