package access specifier not usable within a class

Christophe travert at phare.normalesup.org
Fri Sep 9 05:46:06 PDT 2011


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.


More information about the Digitalmars-d-learn mailing list