View mode: basic / threaded / horizontal-split · Log in · Help
October 19, 2012
Re: Friends?
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 :)
October 19, 2012
Re: Friends?
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
October 19, 2012
Re: Friends?
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
October 19, 2012
Re: Friends?
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
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home