Friends?

Nick Sabalausky SeeWebsiteToContactMe at semitwist.com
Fri Oct 19 13:55:59 PDT 2012


On Fri, 19 Oct 2012 14:36:59 -0400
"Jonathan M Davis" <jmdavisProg at gmx.com> wrote:

> On Friday, October 19, 2012 20:01:20 Alex Rønne Petersen wrote:
> > On 19-10-2012 08:23, Jacob Carlborg wrote:
> > > On 2012-10-18 20:51, Philippe Sigaud wrote:
> > >> I mean, the 'package' access modifier.
> > > 
> > > So did I.
> > > 
> > > class Foo
> > > {
> > > 
> > > package void foo () {}
> > > 
> > > }
> > > 
> > > Would, according to the spec, imply a virtual method. But as
> > > Jonathan said, this is a bug in the spec.
> > 
> > What? How is this not an implementation bug? An access modifier
> > shouldn't have anything to do with whether a method is virtual. If
> > people want to have a class hierarchy with virtual functions at
> > package level, let them. This is the most ridiculous arbitrary
> > restriction I have seen to date. :|
> 
> No. Access level in D has _everything_ to do with whether a function
> is virtual or not, because unlike C++, it provides no way to
> explicitly indicate virtual.

Sure we do. By not adding the word 'final'. (May not be "explicit" in a
strict pedantic sense, but it's close enough.)


> In particular, private _must_ be
> non-virtual, or we have serious issues.

I was just about to that that I'd heard this before and agreed with
it, but something just occurred to me:

That would be true if our "private" was like C++'s private and meant
"accessible by this *class* only". Problem is, D doesn't even *have*
that kind of private. Unlike C++, in D, you *can* have outside
code accessing a class's private members. I see no apparent reason why
a private implementation shouldn't be allowed to use inheritance if it
so chooses.


> Now, whether package in
> particular should be virtual or not is arguably arbitrary, but since
> the only reason to have virtual functions is inheritence, it _does_
> make some sense that only public and protected functions would be
> virtual.

I don't see how that makes sense unless the *only* other option besides
public and protected is a C++-style "private". But that's not the case
in D. In D we also have package and a D-style "private" which is really
more of a "module" than actual "private".


> You can go look for discussions on it in the main newsgroup
> though if you want to see Walter and Andrei's exact reasoning on the
> matter.
> 
> - Jonathan M Davis




More information about the Digitalmars-d-learn mailing list