On Wed, 10 Apr 2013 09:56:01 +0100, Manu <turkey...@gmail.com> wrote:
On 10 April 2013 17:01, Paulo Pinto <pj...@progtools.org> wrote:
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.
That really shouldn't be encouraged. Give me an example?
I wrote some crypto code which had a property for the hash size, each
derived class returned it's own size. Now, in this case the property
size() was called rarely, but it's still a valid example.
That said, I agree we don't generally want properties and other
short-and-should-be-inlined methods to be virtual by default. But.. is D
really doing that? I mean /actually/ really doing it.
I have read most of this thread in passing and I've seen the earlier
discussion about classes in libraries etc and TBH I am not sure how/what D
does in those situations. Presumably if D does not have the source for
the library then the library class would have to have all methods virtual
- just in case it was derived from and I guess this is an issue that needs
solving somehow. But, I don't know if this is the case, or if this is
even an actual problem.
That's not the most common case however, the common case is a class you're
compiling with the rest of your classes and in this case D is not going to
make your base class methods (which have not explicitly been overridden)
virtual, they should be non-virtual and optimised/inlined/etc. They just
start out "virtually" virtual until the compiler is finished compiling
them and all derived classes, at that point all non-override base methods
should be non-virtual.
It would be interesting to see what the compiler actually does if, for
example, you compile a file with a class then in a separate compile/link
step compile a derived class and link. Does D manage to non-virtual all
non-overridden methods? If so, can it do the same with a lib/dll combo?
That's not an exampe. I want to see a class where every function SHOULD
be
overloaded... That sounds like a nightmare, how can anyone other than the
author ever expect to understand it? The fewer and more deliberately
controlled the virtuals, the better, by almost every measure I can
imagine.
This isn't the reasoning behind making virtual the virtual default for
methods. The reason for doing it was simply so the compiler could be
responsible for figuring it out without you having to label it manually.
You're already labelling the derived class method "override" and that
should be enough. This was a choice of convenience and ultimately
performance because you won't accidentally make a method virtual that
doesn't need to be.
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
