www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - package methods are final? huh?

reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
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.
Oct 02 2016
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
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
Oct 02 2016
parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
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).
Oct 02 2016
prev sibling parent reply Lodovico Giaretta <lodovico giaretart.net> writes:
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.
Oct 02 2016
parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
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)?
Oct 02 2016
parent Lodovico Giaretta <lodovico giaretart.net> writes:
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.
Oct 02 2016