www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - virtual, package, private

reply Robert <jfanatiker gmx.at> writes:
Hi guys!

Why are package/private methods non virtual? This just hit me in a
project, is there any good reason for this? (I know this came up before,
but I can't remember any good answer.)

With module-level-private access virtual private methods absolutely make
sense, for a package even more.

Secondly I followed the virtual by default thread quite in detail and
got convinced that non virtual by default would really be better and I
am tempted all the time to mark my methods virtual, but I can't :-(

It seems that Walter also got convinced and to some degree even Andrei,
so if we really want to do this, we should do it soon. Reasoning: The
related change with required override, just happened (user visible) and
for people fixing their code it would be easiest to fix both at the same
time. It is not necessarily less work, but at least less annoying if you
can do it in one run.

With an explicit virtual keyword, private and package methods could then
also be made virtual.

Just my two cents :-)

Best regards,

Robert
Jun 18 2013
next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
I'm also for an explicit 'virtual' keyword.
But I don't get why private methods should be virtual? That makes 
never sense.
Jun 18 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 18 June 2013 at 07:27:50 UTC, Namespace wrote:
 I'm also for an explicit 'virtual' keyword.
 But I don't get why private methods should be virtual? That 
 makes never sense.

Because the unit of encapsulation in D is the module not the class.
Jun 18 2013
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Tuesday, 18 June 2013 at 07:57:23 UTC, deadalnix wrote:
 On Tuesday, 18 June 2013 at 07:27:50 UTC, Namespace wrote:
 I'm also for an explicit 'virtual' keyword.
 But I don't get why private methods should be virtual? That 
 makes never sense.

Because the unit of encapsulation in D is the module not the class.

Still it does not make sense. If a method is supposed to be overridable by others but not visible outside of the class that is what protected is for. I have experience in several OO languages and I consider C++'s private virtual belongs to the same dustbin as checked exceptions, as I am yet to find any design scenario where it makes sense. -- Paulo
Jun 18 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 18 June 2013 at 08:34:51 UTC, Paulo Pinto wrote:
 On Tuesday, 18 June 2013 at 07:57:23 UTC, deadalnix wrote:
 On Tuesday, 18 June 2013 at 07:27:50 UTC, Namespace wrote:
 I'm also for an explicit 'virtual' keyword.
 But I don't get why private methods should be virtual? That 
 makes never sense.

Because the unit of encapsulation in D is the module not the class.

Still it does not make sense. If a method is supposed to be overridable by others but not visible outside of the class that is what protected is for. I have experience in several OO languages and I consider C++'s private virtual belongs to the same dustbin as checked exceptions, as I am yet to find any design scenario where it makes sense.

private in D don't have the same meaning as private in C++ . You are comparing apple and oranges.
Jun 18 2013
prev sibling next sibling parent Robert <jfanatiker gmx.at> writes:
On Tue, 2013-06-18 at 10:34 +0200, Paulo Pinto wrote:
 If a method is supposed to be overridable by others but not 
 visible outside of the class that is what protected is for.

It is like protected, but restricts it to classes in the current module. This is useful at times, if you have a well known hierarchy that should not be extended by third parties. Whether this is good design or not, is debatable, I had some use cases where it made sense for me. Regardless, I don't see why the language should disallow it, except for performance reasons because virtual is the default. If this default is changed, I really see no reasons to disallow it.
Jun 18 2013
prev sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Tuesday, 18 June 2013 at 09:48:13 UTC, Robert wrote:
 On Tue, 2013-06-18 at 10:34 +0200, Paulo Pinto wrote:
 If a method is supposed to be overridable by others but not 
 visible outside of the class that is what protected is for.

It is like protected, but restricts it to classes in the current module. This is useful at times, if you have a well known hierarchy that should not be extended by third parties. Whether this is good design or not, is debatable, I had some use cases where it made sense for me. Regardless, I don't see why the language should disallow it, except for performance reasons because virtual is the default. If this default is changed, I really see no reasons to disallow it.

But then it overlaps partially with package, right? Oh, well need to have a look at the right meanings. This is what happens when I don't use the language that much. Sorry about the confusion, Paulo
Jun 18 2013