www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - package access specifier not usable within a class

reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
abstract class Foo
{
    package void test();
}

class Bar : Foo
{
    override package void test() { }
}

function test.Bar.test cannot override a non-virtual function

TDPL says package can only be used at class-level (i.e. package class
Bar : Foo), outside classes or inside a struct.

I want to hide a virtual method from client code, but another free
function in a different module but in the same package as these
classes needs access to that method. Are there any technical reasons
why package is not allowed for virtual methods?
Sep 08 2011
parent reply travert phare.normalesup.org (Christophe) writes:
Andrej Mitrovic , dans le message (digitalmars.D.learn:29388), a écrit :

 abstract class Foo
 {
     package void test();
 }
 
 class Bar : Foo
 {
     override package void test() { }
 }
 
 function test.Bar.test cannot override a non-virtual function
 
 TDPL says package can only be used at class-level (i.e. package class
 Bar : Foo), outside classes or inside a struct.
 
 I want to hide a virtual method from client code, but another free
 function in a different module but in the same package as these
 classes needs access to that method. Are there any technical reasons
 why package is not allowed for virtual methods?


private function are not virtual.
"All non-static non-private non-template member functions are virtual"
The spirit of this is that if a function is private, it should not be 
seen by its subclasses, which makes sens. However, this is a bit 
inconsistent with the fact that it can actually be seen by the whole 
file. It seems that package function inherited from the same behavior, 
enlarging this inconsistency.

Your request seem to be reasonable, so I would say the langage should be 
improved in two ways:
- private (and package) function can be specifically made virtual, but  
the problem is that virtual is not a keyword in d, and that would be 
weird to have to write final sometimes, and virtual some other times.
- package function are virtual by default, which is the best solution 
IMO. It's not a huge problem if private methods cannot be virtual, if 
you can make them package virtual.

In the meantime, I would make the method public, but prefix the name 
with an underscore to indicate it is morally private. I agree that it is 
relying on the client's good will.

-- 
Christophe
Sep 09 2011
parent reply travert phare.normalesup.org (Christophe) writes:
Christophe, dans le message (digitalmars.D.learn:29394), a écrit :

 Andrej Mitrovic , dans le message (digitalmars.D.learn:29388), a écrit :

 abstract class Foo
 {
     package void test();
 }
 
 class Bar : Foo
 {
     override package void test() { }
 }
 
 function test.Bar.test cannot override a non-virtual function
 
 TDPL says package can only be used at class-level (i.e. package class
 Bar : Foo), outside classes or inside a struct.
 
 I want to hide a virtual method from client code, but another free
 function in a different module but in the same package as these
 classes needs access to that method. Are there any technical reasons
 why package is not allowed for virtual methods?


 
 private function are not virtual.
 "All non-static non-private non-template member functions are virtual"
 The spirit of this is that if a function is private, it should not be 
 seen by its subclasses, which makes sens. However, this is a bit 
 inconsistent with the fact that it can actually be seen by the whole 
 file. It seems that package function inherited from the same behavior, 
 enlarging this inconsistency.
 
 Your request seem to be reasonable, so I would say the langage should be 
 improved in two ways:
 - private (and package) function can be specifically made virtual, but  
 the problem is that virtual is not a keyword in d, and that would be 
 weird to have to write final sometimes, and virtual some other times.
 - package function are virtual by default, which is the best solution 
 IMO. It's not a huge problem if private methods cannot be virtual, if 
 you can make them package virtual.
 
 In the meantime, I would make the method public, but prefix the name 
 with an underscore to indicate it is morally private. I agree that it is 
 relying on the client's good will.
 
 -- 
 Christophe


I forgot about protected. Making the function protected may be fine.
Sep 09 2011
parent SourceCode <rswhite4 googlemail.com> writes:
But what if i had something like this:

abstract class A {
package:
   abstract void _test() const;
}

class B : public A {
package:
    override void _test() const { writeln("Call B::test"); }
}

class C {
public:
    void do_something(const B b) {
        b._test();
    }
}

That only work if i define the method public. But Imo that must
work, because that is imo the correct use of package.
Oct 27 2011