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

I'm also for an explicit 'virtual' keyword.
But I don't get why private methods should be virtual? That makes never sense.

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.

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

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.

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.

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