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.