On Wednesday, 10 April 2013 at 04:32:52 UTC, Manu wrote:
final on the class means you can't derive it anymore (what's
the point of a
class?),
I think that you'd place final on a derived class, not a base
class. So it can make perfect sense, although final on the
methods of a final class makes little sense so it should probably
be a compiler error.
and the manual final blocks are totally prone to error.
In my experience, 90% of functions are not (or rather, should
not be)
virtual. The common (and well performing) case should be
default.
Believe it or not, but I actually have been in the reverse
position more than once, so which way the default should go is
debatable. In your case I can certainly see why you'd prefer the
opposite as I've done RT programming before and will be doing it
again. What could perhaps work is a module level specifier that
indicates what the defaults should be as a matter of use case
preference, but I can see that going horribly wrong.
The question I have, is why use a class if you do not need to use
virtual functions? I think the problem goes a bit deeper than the
defaults being opposite of what you want. I expect that you'd
probably want struct inheritance or something like that but
cannot get it from D?
Any language with properties can't have virtual-by-default.
Seriously, .length or any other trivial property that can no
longer be
inlined, or even just called.
And human error aside, do you really want to have to type final
on every
function? Or indent every line an extra tab level?
Mark your properties as final?
[...]
I don't want to ban the use of virtual functions. I want to ban
the use of
virtual functions that aren't marked virtual explicitly! ;)
Likewise, I like the GC, I just want to be able to control it.
Disable auto-collect, explicitly issue collect calls myself at
controlled
moments, and give the collect function a maximum timeout where
it will
yield, and then resume where it left off next time I call it.
I agree 100% and have that need too. I'd go further and also
prefer the ability to optionally ban certain language features
from use from within selective parts of my code base. As you say,
I do not actually want to outright ban the GC or any other
language feature (I really do use them!!!), it's only the desire
to be able to have much better control over it for the situations
that demand precision and certainty.
Having control over D and the GC like what we're taking about in
here can turn D into a seriously awesome systems language unlike
any other.
--rt
