• Robert (20/20) Jun 18 2013 Hi guys!
• Namespace (3/3) Jun 18 2013 I'm also for an explicit 'virtual' keyword.
• deadalnix (3/6) Jun 18 2013 Because the unit of encapsulation in D is the module not the
• Paulo Pinto (10/16) Jun 18 2013 Still it does not make sense.
• deadalnix (3/18) Jun 18 2013 private in D don't have the same meaning as private in C++ . You
• Robert (9/11) Jun 18 2013 It is like protected, but restricts it to classes in the current module.
• Paulo Pinto (6/23) Jun 18 2013 But then it overlaps partially with package, right?

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

"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.

"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.

"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

"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.

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.

"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