Private methods can't be overridden?
in [Java Programming]
|
Prev: Can I install new JavaRuntime version on top of previous? Automatic (CLASS)PATH change?
Next: [ANN] XMLmind MultipartRequest
From: Mike Schilling on 19 Feb 2010 02:44 Peter Duniho wrote: > Mike Schilling wrote: >> "Peter Duniho" <NpOeStPeAdM(a)NnOwSlPiAnMk.com> wrote in message >> news:ccednWWwHYGkhePWnZ2dnUVZ_jednZ2d(a)posted.palinacquisition... >>> Anyway, that's a long way of saying that, while it's been almost a >>> decade since I've done any significant C++ programming, I've never >>> heard of a rule of thumb to make virtual methods private in C++, >>> and it seems like such a rule would simply trade one inconvenience >>> for another. The versioning issue is certainly something to be >>> aware of, but it doesn't seem like justification for always making >>> virtual methods private. >> >> I expalined upthread what that pattern is for: in brief, it's a way >> of ensuring that the virtual methods are called with the proper >> prolog and postlog. > > Sorry, I don't understand that explanation. What makes virtual > methods special such that they, and no other kinds of methods, > requires that pattern? > > Seems like that's a pattern you'd apply to methods that have pre- and > post-conditions, whether they are virtual or not. And you would not > apply it to methods that don't have pre- and post-conditions, again > where they are virtual or not. > > Of course, in Java always following that pattern would mean making > every public method "final", and only allowing overrides of > "protected" methods. Obviously, no one does that as a general rule. As I said in the part you snipped, it isn't a general rule. ":make all virtual mrhods private" is a pretty severe oversimplification I described this pattern and how it's implemented in C++ using virtual private functions at http://www.velocityreviews.com/forums/showpost.php?p=4030006&postcount=4
From: Peter Duniho on 19 Feb 2010 03:10 Mike Schilling wrote: > As I said in the part you snipped, it isn't a general rule. Then it seems to me that you aren't actually responding to the original poster's question, which was specifically about a general rule applied to virtual methods in C++. > ":make all > virtual mrhods private" is a pretty severe > oversimplification Of the pattern you've described, sure. But since the pattern you've described has nothing to do with virtual methods per se, why is that pattern relevant to the original question in the first place? You've basically taken a statement that was made about virtual methods, and presented a completely unrelated pattern, and then accused the statement of being a severe oversimplification of that completely unrelated pattern. There seems to be a missing logical link there. Of course, if the original statement about virtual methods _were_ in fact based on the pattern you describe, it would be a severe oversimplification of that pattern. But no one has asserted that it is in fact based on the pattern you describe, except you. So, before we talk about it being a severe oversimplification of the pattern you describe, it seems to me we need to establish that it is in any way related to the pattern you describe. So far, that hasn't been established, and there's a great deal of evidence that it is in fact not related to the pattern you describe in any way, shape, or form. Can you provide a non-tautological connection between the original statement made about virtual methods and the pattern you've described? Pete
From: Mike Schilling on 19 Feb 2010 04:01 Peter Duniho wrote: > Mike Schilling wrote: >> As I said in the part you snipped, it isn't a general rule. > > Then it seems to me that you aren't actually responding to the > original poster's question, which was specifically about a general > rule applied to virtual methods in C++. To quote: >>> I heard from people that do C++ that it is a good idea to make virtual >>> methods private and public functions non-virtual >>> (non-virtual-interface). That is, the OP was reporting something he'd heard about, not a practice he'd followed or studied in detail. I've never heard of such a blanket rule for C++. (I haven't coded in C++ for a while, but I did so almost exclusively for about 6 years.) Have you? Has anyone?
From: Arved Sandstrom on 19 Feb 2010 06:00 Mike Schilling wrote: > Peter Duniho wrote: >> Mike Schilling wrote: >>> As I said in the part you snipped, it isn't a general rule. >> Then it seems to me that you aren't actually responding to the >> original poster's question, which was specifically about a general >> rule applied to virtual methods in C++. > > To quote: > >>>> I heard from people that do C++ that it is a good idea to make virtual >>>> methods private and public functions non-virtual >>>> (non-virtual-interface). > > That is, the OP was reporting something he'd heard about, not a practice > he'd followed or studied in detail. I've never heard of such a blanket rule > for C++. (I haven't coded in C++ for a while, but I did so almost > exclusively for about 6 years.) Have you? Has anyone? I haven't coded in C++ as much as you, maybe 2-3 years total for real, otherwise all along for 20 odd years I have simply tried to stay au courant in case I need the language at short notice. :-) I have frequently encountered people saying two opposite things: namely, make most virtual methods public, or make most of them private. For example, the Marshall Cline C++ FAQ for "public" (http://www.parashift.com/c++-faq-lite/strange-inheritance.html#faq-23.4), and Herb Sutter in his NVI article (http://www.gotw.ca/publications/mill18.htm) for "private". One might think that there are special circumstances here that situationally separate the viewpoints, but I've never distinguished any - it simply looks like opposing philosophies. Myself I can see the argument for private virtuals: you're making a statement that you've got a default implementation but it's overridable, and if you do override you have to completely customize - no calling the base method. It occurs to me that in Java I encounter both situations equally often - I'm either adapting the parent method behaviour and hence call the parent method somewhere in the child method, or I don't need the parent method at all and hence never call it. We don't have a mechanism in Java for expressing the latter strongly, as in you can't ever call the parent method when overriding. But I suspect a lot of people are happiest with C#: non-virtual methods by default (so you have to declare them virtual), but you cannot have a private virtual. AHS
From: Johannes Schaub (litb) on 19 Feb 2010 07:26
Arved Sandstrom wrote: > Mike Schilling wrote: >> Peter Duniho wrote: >>> Mike Schilling wrote: >>>> As I said in the part you snipped, it isn't a general rule. >>> Then it seems to me that you aren't actually responding to the >>> original poster's question, which was specifically about a general >>> rule applied to virtual methods in C++. >> >> To quote: >> >>>>> I heard from people that do C++ that it is a good idea to make >>>>> virtual >>>>> methods private and public functions non-virtual >>>>> (non-virtual-interface). >> >> That is, the OP was reporting something he'd heard about, not a practice >> he'd followed or studied in detail. I've never heard of such a blanket >> rule for C++. (I haven't coded in C++ for a while, but I did so almost >> exclusively for about 6 years.) Have you? Has anyone? > > I haven't coded in C++ as much as you, maybe 2-3 years total for real, > otherwise all along for 20 odd years I have simply tried to stay au > courant in case I need the language at short notice. :-) I have > frequently encountered people saying two opposite things: namely, make > most virtual methods public, or make most of them private. For example, > the Marshall Cline C++ FAQ for "public" > (http://www.parashift.com/c++-faq-lite/strange-inheritance.html#faq-23.4), > and Herb Sutter in his NVI article > (http://www.gotw.ca/publications/mill18.htm) for "private". > Exactly, i was getting this guideline from herb's sutter NVI article, and it looked like a good thing to me. But people here made a good point, in that private methods should be independent of anything the derived class does. And here is where the philosophy comes, i think. While in Java, a private seems to mean "entirely hide its existence from derived classes", in C++ it means "don't hide it, but rise an error if its name is used by others". One point views private methods as *really* private, without any connection whatsoever to the derived class. The other one sees private methods as just forbidding any other class to call it, but otherwise having certain connections (like, being able to override it if virtual). |