module x.a;

class A
{
package:
  int f()
  {
    return 0;
  }
}


============================
module x.b;

import x.a;

class B : A
{
package:
  override int f()
  {
    return 0;
  }
}

> error : function x.b.B.f package method is not virtual and cannot override

Why? I have a UI system with modules for each node type. UI internal stuff is naturally 'package'. Virtuals are perfectly reasonable within a package.

On 03/10/2016 12:37 AM, Manu via Digitalmars-d wrote:
> module x.a;
>
> class A
> {
> package:
>   int f()
>   {
>     return 0;
>   }
> }
>
>
> ============================
> module x.b;
>
> import x.a;
>
> class B : A
> {
> package:
>   override int f()
>   {
>     return 0;
>   }
> }
>
>> error : function x.b.B.f package method is not virtual and cannot override
>
> Why? I have a UI system with modules for each node type. UI internal
> stuff is naturally 'package'. Virtuals are perfectly reasonable within
> a package.

I would recommend using the explicit form of package ``package(x):`` although no idea if that'll help you out here.


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

On Sunday, 2 October 2016 at 11:37:34 UTC, Manu wrote:
> [...]
>
> Why? I have a UI system with modules for each node type. UI internal stuff is naturally 'package'. Virtuals are perfectly reasonable within a package.

One reason I can think of: what happens if someone outside the package extends one of your classes?

===================================

module packA.something;

class Base
{
    abstract void foo();
}

module packB.something;

class Derived1: Base
{
    override void foo() {}     // Oops... should not know about this method,
                               //         but without it the class is abstract.
}
===================================

The fact is, package virtual is fine as long as the class cannot be extended outside the package, or can be extended outside the package but no subclass defined in this way may need a different definition of the method. Such a constraint is difficult to enforce in the language.

On 2 October 2016 at 21:40, rikki cattermole via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 03/10/2016 12:37 AM, Manu via Digitalmars-d wrote:
>>
>> module x.a;
>>
>> class A
>> {
>> package:
>>   int f()
>>   {
>>     return 0;
>>   }
>> }
>>
>>
>> ============================
>> module x.b;
>>
>> import x.a;
>>
>> class B : A
>> {
>> package:
>>   override int f()
>>   {
>>     return 0;
>>   }
>> }
>>
>>> error : function x.b.B.f package method is not virtual and cannot override
>>
>>
>> Why? I have a UI system with modules for each node type. UI internal stuff is naturally 'package'. Virtuals are perfectly reasonable within a package.
>
>
> I would recommend using the explicit form of package ``package(x):`` although no idea if that'll help you out here.

It makes no difference. (I actually do use this form).

On 2 October 2016 at 21:51, Lodovico Giaretta via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Sunday, 2 October 2016 at 11:37:34 UTC, Manu wrote:
>>
>> [...]
>>
>> Why? I have a UI system with modules for each node type. UI internal stuff is naturally 'package'. Virtuals are perfectly reasonable within a package.
>
>
> One reason I can think of: what happens if someone outside the package extends one of your classes?
>
> ===================================
>
> module packA.something;
>
> class Base
> {
>     abstract void foo();
> }
>
> module packB.something;
>
> class Derived1: Base
> {
>     override void foo() {}     // Oops... should not know about this method,
>                                //         but without it the class is
> abstract.
> }
> ===================================
>
> The fact is, package virtual is fine as long as the class cannot be extended outside the package, or can be extended outside the package but no subclass defined in this way may need a different definition of the method. Such a constraint is difficult to enforce in the language.

Why would something outside the package be able to see the package
function to override it?
Surely the override would report an inaccessibility error (referring
to the base virtual)?

On Sunday, 2 October 2016 at 12:21:19 UTC, Manu wrote:
> Why would something outside the package be able to see the package
> function to override it?
> Surely the override would report an inaccessibility error (referring
> to the base virtual)?

1) Usually a virtual function is also allowed to be abstract. Subclasses defined outside the package will not be able to implement that virtual function and will either fail compilation or crash at runtime.

2) Virtual functions are part of the public interface, as they partecipate in the vtable layout. So, allowing package virtuals, non-public functions would become part of the public interface.

3) A virtual method performs operations specific for each subclass (otherwise, there's no reason for having it virtual); what if a subclass defined outside of the package requires a different override?

I'm not saying that package functions should not be virtual at all. I'm saying that this thing must be carefully thought, as it doesn't really play well with cross-package inheritance.

By the way, the same discussion could be made for having private methods be virtual, as private applies to the module level, and a module may contain an entire hierarchy of classes.