Final by default?

Manu turkeyman at gmail.com
Sat Mar 15 03:29:57 PDT 2014


On 15 March 2014 18:50, Daniel Murphy <yebbliesnospam at gmail.com> wrote:

> "Walter Bright"  wrote in message news:lg0vtc$2q94$1 at 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140315/50142b69/attachment.html>


More information about the Digitalmars-d mailing list