On 2011-06-03 11:13, Michael Shulman wrote: > On Thu, Jun 2, 2011 at 11:55 PM, Jonathan M Davis <jmdavisp...@gmx.com> wrote: > > I don't really like the idea of private functions being virtual > > by default though, so maybe your suggestion would be a good one. > > Speaking as a newbie with very little D experience, the idea of > private functions being non-virtual would make perfect sense to me if > 'private' meant restricted to a single class, as it does in C++. The > situation of a derived class being able to override a private function > from an interface or base class, but not *call* the overridden > function, seems a bit weird and pointless; using 'protected' does make > more sense to me for that use case.
Actually, C++ has exactly this behavior. You can overload private functions in C++. That's where the whole Non-Virtual Interface paradigm came from, I believe. However, in C++, functions are only virtual if you make them virtual (which you don't normally do with private functions unless you're doing NVI), unlike D. > However, given that in D, 'private' only means restricted to a > *module*, it's less clear to me why private functions should be > singled out as non-virtual. I might want certain methods to be > accessible only within a given module, but still allow them to be > overridden within a class hierarchy that exists entirely inside that > module. Unless the point of view is that each class should always > exist in its own module? No, there would be nothing wrong with overriding private member functions within a module with derived classes (assuming that private were overridable). That would be a bit weird, generally-speaking, but it would be perfectly legitimate. There are no restrictions on how many classes or structs you put in a module, and the core D community does not seem to think that code should necessarily be divided that way. For instance, both std.container and std.datetime in Phobos have multiple types defined within them. So, you could define as many classes or structs in a module as you want to. The main issue would be if the module got too large (which some have accussed std.datetime of doing). - Jonathan M Davis