private method in interface

[Jonathan M Davis]

On 2011-06-03 11:13, Michael Shulman wrote:
> On Thu, Jun 2, 2011 at 11:55 PM, Jonathan M Davis <jmdavisProg at 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