On Thu, Oct 18, 2012 at 10:44 PM, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
>> Does it work? I thought it was not implemented.
>
> Hmm. I don't know what it's current state is. There _is_ a long-standing bug on it in bugzilla ( http://d.puremagic.com/issues/show_bug.cgi?id=143 ) which is still open. I had forgotten about it. But the bug is that package doesn't restrict when it's supposed to as opposed to restricting when it's not supposed to, so it'll work in that you can use it correctly and have your code work, but it won't catch incorrect usage, and your code which uses it incorrectly will break once it's fixed.

Ah, I see. I filed it mentally into my 'non-implemented-see-later' slot back in 2008 or 2009 when I began with D :)

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. :|

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org

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. In particular, private _must_ be non-virtual, or we have serious issues. 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. 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

On Fri, 19 Oct 2012 14:36:59 -0400
"Jonathan M Davis" <jmdavisProg@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