www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - private is non-virtual: Stuck in C++-thinking?

reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
My understanding is that this is intentionally disallowed:

---------------------------
module foo;

class Foo
{
    private void func() {}
}

class Bar : Foo
{
    // Disallowed:
    private override void func() {}
}

void foobar(Foo f)
{
    f.func();
}
---------------------------

If D had C++'s "private", that restriction would make a lot of sense
(except possibly for nested classes, but I dunno). That's because: How
can you override a class you can't even access?

But D doesn't have a "true" private in the C++ sense. Instead, there
is code outside a class which *is* permitted to access "private"
members.

So am I missing something, or was the sample case above overlooked when
making the "private must be non-virtual" decision?
Oct 19 2012
next sibling parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Friday, 19 October 2012 at 21:09:05 UTC, Nick Sabalausky wrote:
 My understanding is that this is intentionally disallowed:

 ---------------------------
 module foo;

 class Foo
 {
     private void func() {}
 }

 class Bar : Foo
 {
     // Disallowed:
     private override void func() {}
 }

 void foobar(Foo f)
 {
     f.func();
 }
 ---------------------------

 If D had C++'s "private", that restriction would make a lot of 
 sense
 (except possibly for nested classes, but I dunno). That's 
 because: How
 can you override a class you can't even access?

 But D doesn't have a "true" private in the C++ sense. Instead, 
 there
 is code outside a class which *is* permitted to access "private"
 members.

 So am I missing something, or was the sample case above 
 overlooked when
 making the "private must be non-virtual" decision?
According to TDPL, this should be legal. In particular, there is an entire section about it regarding NVI. No idea what it going on, but I'm curious for answers.
Oct 19 2012
next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Friday, 19 October 2012 at 21:22:28 UTC, monarch_dodra wrote:
 On Friday, 19 October 2012 at 21:09:05 UTC, Nick Sabalausky
 So am I missing something, or was the sample case above 
 overlooked when
 making the "private must be non-virtual" decision?
According to TDPL, this should be legal. In particular, there is an entire section about it regarding NVI. No idea what it going on, but I'm curious for answers.
It's a bug. http://d.puremagic.com/issues/show_bug.cgi?id=3581 http://d.puremagic.com/issues/show_bug.cgi?id=4542
Oct 19 2012
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, October 19, 2012 23:22:26 monarch_dodra wrote:
 According to TDPL, this should be legal. In particular, there is
 an entire section about it regarding NVI.
 
 No idea what it going on, but I'm curious for answers.
For interfaces, where it's doing something to specifically enable NVI. It never says that for classes. It's been discussed a number of times before, and I think that it's fairly clear that Walter has no intention of changing it. Regardless, it would actually be a _huge_ problem for private to be virtual, and it's completely unnecessary for NVI (protected does the job just fine). If private were virtual, then it that would kill inlining and any other optimization relying on knowing the body of the function or anything else which gets affected by a function being virtual - including the cost of the vtable lookup. You would be forced to mark all private functions as final to fix this, which most people won't do, which would lead to performance hits everywhere where classes are used. Classes in D would be less performant for essentially _zero_ gain. If you want virtual but don't want the function to be public, then use protected. - Jonathan M Davis
Oct 19 2012
parent reply deadalnix <deadalnix gmail.com> writes:
Le 20/10/2012 01:14, Jonathan M Davis a écrit :
 On Friday, October 19, 2012 23:22:26 monarch_dodra wrote:
 According to TDPL, this should be legal. In particular, there is
 an entire section about it regarding NVI.

 No idea what it going on, but I'm curious for answers.
For interfaces, where it's doing something to specifically enable NVI. It never says that for classes. It's been discussed a number of times before, and I think that it's fairly clear that Walter has no intention of changing it. Regardless, it would actually be a _huge_ problem for private to be virtual, and it's completely unnecessary for NVI (protected does the job just fine). If private were virtual, then it that would kill inlining and any other optimization relying on knowing the body of the function or anything else which gets affected by a function being virtual - including the cost of the vtable lookup.
Yes, if you don't want that, just define this a a private free function. D isn't some kind of language where everything need to be an object.
Oct 23 2012
parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, October 23, 2012 21:34:35 deadalnix wrote:
 Le 20/10/2012 01:14, Jonathan M Davis a écrit :
 On Friday, October 19, 2012 23:22:26 monarch_dodra wrote:
 According to TDPL, this should be legal. In particular, there is
 an entire section about it regarding NVI.
 
 No idea what it going on, but I'm curious for answers.
For interfaces, where it's doing something to specifically enable NVI. It never says that for classes. It's been discussed a number of times before, and I think that it's fairly clear that Walter has no intention of changing it. Regardless, it would actually be a _huge_ problem for private to be virtual, and it's completely unnecessary for NVI (protected does the job just fine). If private were virtual, then it that would kill inlining and any other optimization relying on knowing the body of the function or anything else which gets affected by a function being virtual - including the cost of the vtable lookup.
Yes, if you don't want that, just define this a a private free function. D isn't some kind of language where everything need to be an object.
That's no better than expecting programmers to mark all of their private functions final. It's not what they'll do normally, so they'll end up with slower code and complain about it. It just makes things slow by default, and being able to override private functions gains you pretty much _nothing_. _All_ that it does is make it impossible to call the base class implementation of the function. You can still call the implementation in the derived class. protected will do _exactly_ the same thing for you except that derived classes will be able to call the base class implementation rather than just their own. Making it impossible to call the base class implementation isn't even vaguely worth the performance costs that then affects almost every class ever written in D. - Jonathan M Davis
Oct 23 2012
prev sibling parent reply "foobar" <foo bar.com> writes:
On Friday, 19 October 2012 at 21:09:05 UTC, Nick Sabalausky wrote:
 My understanding is that this is intentionally disallowed:

 ---------------------------
 module foo;

 class Foo
 {
     private void func() {}
 }

 class Bar : Foo
 {
     // Disallowed:
     private override void func() {}
 }

 void foobar(Foo f)
 {
     f.func();
 }
 ---------------------------

 If D had C++'s "private", that restriction would make a lot of 
 sense
 (except possibly for nested classes, but I dunno). That's 
 because: How
 can you override a class you can't even access?

 But D doesn't have a "true" private in the C++ sense. Instead, 
 there
 is code outside a class which *is* permitted to access "private"
 members.

 So am I missing something, or was the sample case above 
 overlooked when
 making the "private must be non-virtual" decision?
virtual private is an obscure C++ idiom which I think the argument for is extremely week. I think Walter made the right decision here in favor of more readable code. I'd do the following: --------------------------- module foo; class Foo { private void func() { funcImpl(); } protected void funcImpl() {} } class Bar : Foo { protected override void funcImpl() {} } void foobar(Foo f) { f.func(); } ---------------------------
Oct 19 2012
next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sat, 20 Oct 2012 00:18:28 +0200
"foobar" <foo bar.com> wrote:
 
 virtual private is an obscure C++ idiom which I think the 
 argument for is extremely week.
Well like I said though, virtual private is *very* different in C++ than it is in D, because private itself is very different in C++ than in D.
 I think Walter made the right 
 decision here in favor of more readable code.
 
Oct 19 2012
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Friday, 19 October 2012 at 22:18:29 UTC, foobar wrote:
 virtual private is an obscure C++ idiom which I think the 
 argument for is extremely week. I think Walter made the right 
 decision here in favor of more readable code.
Really? it is the entire point of NVI. I've seen it used all the time. It is even used (and documented) in the STL, as the way to customize streams... On Friday, 19 October 2012 at 23:14:32 UTC, Jonathan M Davis wrote:
 On Friday, October 19, 2012 23:22:26 monarch_dodra wrote:
 According to TDPL, this should be legal. In particular, there 
 is
 an entire section about it regarding NVI.
 
 No idea what it going on, but I'm curious for answers.
For interfaces, where it's doing something to specifically enable NVI. It never says that for classes.
Good point. I've not much experience with interfaces yet, so the difference didn't strike at me. Yeah, once you define an interface, I guess the point of virtual private-ness becomes moot.
Oct 20 2012
prev sibling parent deadalnix <deadalnix gmail.com> writes:
Le 20/10/2012 00:18, foobar a écrit :
 On Friday, 19 October 2012 at 21:09:05 UTC, Nick Sabalausky wrote:
 My understanding is that this is intentionally disallowed:

 ---------------------------
 module foo;

 class Foo
 {
 private void func() {}
 }

 class Bar : Foo
 {
 // Disallowed:
 private override void func() {}
 }

 void foobar(Foo f)
 {
 f.func();
 }
 ---------------------------

 If D had C++'s "private", that restriction would make a lot of sense
 (except possibly for nested classes, but I dunno). That's because: How
 can you override a class you can't even access?

 But D doesn't have a "true" private in the C++ sense. Instead, there
 is code outside a class which *is* permitted to access "private"
 members.

 So am I missing something, or was the sample case above overlooked when
 making the "private must be non-virtual" decision?
virtual private is an obscure C++ idiom which I think the argument for is extremely week. I think Walter made the right decision here in favor of more readable code. I'd do the following: --------------------------- module foo; class Foo { private void func() { funcImpl(); } protected void funcImpl() {} } class Bar : Foo { protected override void funcImpl() {} } void foobar(Foo f) { f.func(); } ---------------------------
Being able to define function but prevent from calling them is a very usefull thing. Especially when you want to allow to redefine behavior that would let the object in an invalid state.
Oct 23 2012