www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Package and virtual functions

reply "BLM768" <blm768 gmail.com> writes:
For some reason, whenever I declare a method with package 
visibility, it becomes non-virtual. Is this normal behavior, or 
is there a bug in DMD 2.059?
Jun 13 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, June 14, 2012 00:32:45 BLM768 wrote:

 For some reason, whenever I declare a method with package
 visibility, it becomes non-virtual. Is this normal behavior, or
 is there a bug in DMD 2.059?


Only public and protected functions can be virtual. private and package 
functions are never virtual. This is by design.

- Jonathan M Davis
Jun 13 2012
next sibling parent reply "BLM768" <blm768 gmail.com> writes:
On Wednesday, 13 June 2012 at 22:48:34 UTC, Jonathan M Davis 
wrote:

 On Thursday, June 14, 2012 00:32:45 BLM768 wrote:

 For some reason, whenever I declare a method with package
 visibility, it becomes non-virtual. Is this normal behavior, or
 is there a bug in DMD 2.059?


 Only public and protected functions can be virtual. private and 
 package
 functions are never virtual. This is by design.

 - Jonathan M Davis


That explains it. I kind of wish I'd known that a few hours ago :)
It would be nice if DMD would issue a warning when redefining a 
non-virtual function in a subclass. I might have to start using 
"override" more often despite force of habit and dislike of its 
verboseness. Perhaps "override" should be implied by default 
since it's by far the most common case. In cases where the 
programmer really wants to redefine the function non-virtually, 
there could be a keyword that would handle that. It could reduce 
extra typing and save beginners hours of stress :)
Jun 13 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, June 14, 2012 01:07:17 BLM768 wrote:

 On Wednesday, 13 June 2012 at 22:48:34 UTC, Jonathan M Davis
 
 wrote:

 On Thursday, June 14, 2012 00:32:45 BLM768 wrote:

 For some reason, whenever I declare a method with package
 visibility, it becomes non-virtual. Is this normal behavior, or
 is there a bug in DMD 2.059?


 
 Only public and protected functions can be virtual. private and
 package
 functions are never virtual. This is by design.
 
 - Jonathan M Davis


 
 That explains it. I kind of wish I'd known that a few hours ago :)
 It would be nice if DMD would issue a warning when redefining a
 non-virtual function in a subclass. I might have to start using
 "override" more often despite force of habit and dislike of its
 verboseness. Perhaps "override" should be implied by default
 since it's by far the most common case. In cases where the
 programmer really wants to redefine the function non-virtually,
 there could be a keyword that would handle that. It could reduce
 extra typing and save beginners hours of stress :)


override will eventually be required when overriding a function. It is already 
if you compile with -w but not yet all of the time - though since protected 
isn't virtual and isn't really overriding anything, the compiler doesn't 
complain if you don't use override with it (though it will if you do, since 
it's not overriding anything). So, eventually (or now if you use -w), you will 
_always_ know whether a function is overiding another or not, because it will 
have to have override if it is and can't have it if it isn't.

- Jonathan M Davis
Jun 13 2012
parent reply "BLM768" <blm768 gmail.com> writes:
 override will eventually be required when overriding a 
 function. It is already
 if you compile with -w but not yet all of the time - though 
 since protected
 isn't virtual and isn't really overriding anything, the 
 compiler doesn't
 complain if you don't use override with it (though it will if 
 you do, since
 it's not overriding anything). So, eventually (or now if you 
 use -w), you will
 _always_ know whether a function is overiding another or not, 
 because it will
 have to have override if it is and can't have it if it isn't.

 - Jonathan M Davis


That's good to know. I'll start using -w from now on.
However, the problem still exists that if a function is meant to 
override a virtual method, but the method is not actually 
virtual, and the programmer forgets to type "override," the 
compiler won't complain and the error will slip through.
Jun 13 2012
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 06/14/2012 01:34 AM, BLM768 wrote:

 override will eventually be required when overriding a function. It is
 already
 if you compile with -w but not yet all of the time - though since
 protected
 isn't virtual and isn't really overriding anything, the compiler doesn't
 complain if you don't use override with it (though it will if you do,
 since
 it's not overriding anything). So, eventually (or now if you use -w),
 you will
 _always_ know whether a function is overiding another or not, because
 it will
 have to have override if it is and can't have it if it isn't.

 - Jonathan M Davis


 That's good to know. I'll start using -w from now on.
 However, the problem still exists that if a function is meant to
 override a virtual method, but the method is not actually virtual, and
 the programmer forgets to type "override," the compiler won't complain
 and the error will slip through.


True, but it will be explicit in the derived class code:
No 'override', no function that is overridden.
Jun 13 2012
parent reply "BLM768" <blm768 gmail.com> writes:
 True, but it will be explicit in the derived class code:
 No 'override', no function that is overridden.


However, if a programmer expects it to override, there could be 
an issue. Imagine a novice D programmer who is not used to using 
"override" and looks at at the following code:

class Base {
     private:
     void test() {}
}

class Derived: Base {
     private:
     void test() {}
}

He/she would assume (as I did) that Derived.test virtually 
overrides Base.test because there's clearly no "final" attribute 
on Base.test. This subtle quirk could cause (as it did in my 
code) somewhat subtle and very frustrating bugs. It might be good 
to create a warning in this situation, then have a keyword that 
tells the compiler, "Yes, I really did mean to redefine a 
non-virtual function."
Jun 13 2012
parent reply "BLM768" <blm768 gmail.com> writes:
I guess that another solution to this whole mess is to just start 
requiring the use of override; then everyone would be educated 
and it would be obvious where the bug is in the code I posted. 
Since we don't want to break code, though, maybe there should be 
a message prominently displayed on the D homepage telling people 
to use the -w switch until the requirement is actually enforced 
for all code. If that requirement is going to be enforced, 
though, I can't think of a better time than now; otherwise, 
people are going to write code without "override" and eventually 
end up making the same mistakes that I did.
Jun 13 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 06/14/2012 01:57 AM, BLM768 wrote:

 I guess that another solution to this whole mess is to just start
 requiring the use of override; then everyone would be educated and it
 would be obvious where the bug is in the code I posted. Since we don't
 want to break code, though, maybe there should be a message prominently
 displayed on the D homepage telling people to use the -w switch until
 the requirement is actually enforced for all code. If that requirement
 is going to be enforced, though, I can't think of a better time than
 now; otherwise, people are going to write code without "override" and
 eventually end up making the same mistakes that I did.


Yes, this is the plan.
Jun 13 2012
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, June 14, 2012 01:34:42 BLM768 wrote:

 override will eventually be required when overriding a
 function. It is already
 if you compile with -w but not yet all of the time - though
 since protected
 isn't virtual and isn't really overriding anything, the
 compiler doesn't
 complain if you don't use override with it (though it will if
 you do, since
 it's not overriding anything). So, eventually (or now if you
 use -w), you will
 _always_ know whether a function is overiding another or not,
 because it will
 have to have override if it is and can't have it if it isn't.
 
 - Jonathan M Davis


 
 That's good to know. I'll start using -w from now on.
 However, the problem still exists that if a function is meant to
 override a virtual method, but the method is not actually
 virtual, and the programmer forgets to type "override," the
 compiler won't complain and the error will slip through.


True enough, but then all it takes is looking at the function to know that 
it's not overriding anything (because it doesn't have override on it), and 
naming a function the same in a derived class when it's not virtual generally 
isn't a good idea, since it's _not_ overriding anything - the same happens 
with both protected and private. But there's really no fix for that other than 
making it illegal to have a private or protected function with the same name 
in derived classes, which then effectively leaks some of the private/protected 
API of the base classes into the derived classes rather than hiding it. So, 
it's not like there's really a perfect solution.

IIRC, the docs are quite clear that protected is non-virtual, but it's 
probably easy to miss.

- Jonathan M Davis
Jun 13 2012
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-06-14 00:48, Jonathan M Davis wrote:

 On Thursday, June 14, 2012 00:32:45 BLM768 wrote:

 For some reason, whenever I declare a method with package
 visibility, it becomes non-virtual. Is this normal behavior, or
 is there a bug in DMD 2.059?


 Only public and protected functions can be virtual. private and package
 functions are never virtual. This is by design.

 - Jonathan M Davis


The docs say:

"All non-static non-private non-template member functions are virtual."

To me that says that methods marked with "package" are virtual. It's 
been like that in the documentation forever. So I don't know if "by 
design" is correct. I also know that package methods have never been 
virtual so I don't know what the actual design is.

This is a common, annoying, problem with D: What is correct when DMD, 
the documentation and TDPL all are different?

http://dlang.org/function.html#virtual-functions

-- 
/Jacob Carlborg
Jun 13 2012
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, June 14, 2012 08:30:26 Jacob Carlborg wrote:

 On 2012-06-14 00:48, Jonathan M Davis wrote:

 On Thursday, June 14, 2012 00:32:45 BLM768 wrote:

 For some reason, whenever I declare a method with package
 visibility, it becomes non-virtual. Is this normal behavior, or
 is there a bug in DMD 2.059?


 
 Only public and protected functions can be virtual. private and package
 functions are never virtual. This is by design.
 
 - Jonathan M Davis


 
 The docs say:
 
 "All non-static non-private non-template member functions are virtual."
 
 To me that says that methods marked with "package" are virtual. It's
 been like that in the documentation forever. So I don't know if "by
 design" is correct. I also know that package methods have never been
 virtual so I don't know what the actual design is.
 
 This is a common, annoying, problem with D: What is correct when DMD,
 the documentation and TDPL all are different?
 
 http://dlang.org/function.html#virtual-functions


I believe that Walter has stated that it's on purpose that package be non-
virtual. I know that Andrei thinks that, since he's said as much when the 
topic has come up. And from discussions on the matter, I believe that it's 
fairly clear that the current behavior is going to stay.

Regardless, the docs clearly need to be fixed.

- Jonathan M Davis
Jun 13 2012