On Monday, 3 June 2013 at 07:30:56 UTC, Kapps wrote:
On Monday, 3 June 2013 at 07:06:05 UTC, Manu wrote:
There are functions that
the author intended to be overridden, and functions that have
no business
being overridden, that the author probably never imagined
anyone would
override.
What if someone does come along and override one of these, and
it was never
designed to work under that circumstance in the first place?
At very least, it will have never been tested. That's not a
very robust API
offering if you ask me.
This is something just as important as the performance issues.
Most of the time people will leave functions to simply use
whatever the default is for virtual/final. If it's final, this
works fairly well. The author hasn't put in the effort to
decide how to handle people overriding their function. But with
virtual by default, you don't know if the author actually
considered that people will be overriding the function or if
it's simply that they didn't bother specifying. I know the vast
majority of my code is virtual, simply because I didn't specify
the 'final' keyword 500 times, and didn't think about that I'd
need to do it. The resulting code is unsafe because I didn't
consider those functions actually being overridden.
The whole concept of OOP revolve around the fact that a given
class and users of the given class don't need to know about its
subclasses (Liskov's substitution principle). It is subclass's
responsibility to decide what it override or not, not the upper
class to decide what is overriden by subclasses.
If you want to create a class with customizable parts, pass
parameters to the constructor. This isn't OOP what OOP is about.
The performance concern is only here because things has been
smashed together in a inconsequent way (as it is often done in
D). In Java for instance, only overriden function are actually
virtual. Everything else is finalized at link time. Which is
great because you are able to override everything when testing to
create mock for instance, while keeping good performance when
actually running the application.
