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