Re: Package and virtual functions
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
Re: Package and virtual functions
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
Re: Package and virtual functions
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
Re: Package and virtual functions
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 :)
Re: Package and virtual functions
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
Re: Package and virtual functions
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.
Re: Package and virtual functions
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.
Re: Package and virtual functions
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.
Re: Package and virtual functions
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.
Re: Package and virtual functions
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.
