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