On Wednesday, 10 April 2013 at 06:03:08 UTC, Manu wrote:
[...]
I do use virtual functions, that's the point of classes. But
most functions
are not virtual. More-so, most functions are trivial accessors,
which
really shouldn't be virtual.
OOP by design recommends liberal use of accessors, ie,
properties, that
usually just set or return a variable. Wen would you ever want
@property
size_t size() { return size; } to be a virtual call?
Yes, if you want to change its behavior in a derived class.
One nice feature of properties is that you can trigger actions
when assigning/reading from properties.
This is very used in OO GUI and DB code in other languages.
Can you demonstrate a high level class, ie, not a primitive
tool, but the
sort of thing a programmer would write in their daily work
where all/most
functions would be virtual?
I have lots of code from JVM and .NET languages with such
examples.
OO code in the enterprise world is a beauty in itself, regardless
of the language.
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.
Precisely.
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.
Correct, it's not quite a systems language while the GC does
whatever it
wants. But D needs the GC to be considered a 'modern', and
generally
productive language.
Maybe something like VisualVM would help as well.
--
Paulo
