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: Lew on 18 Feb 2010 17:59 Johannes Schaub (litb) wrote, quoted or indirectly quoted someone who said : >> I'm sorry. My whole question is about why it *doesn't* compile. I feel like >> you rushed over my question, call me a "troll" and go on giving me tutorials >> that do not seem to answer my question and slapping me for mentioning C++. Roedy Green wrote: > Don't take it personally. Lew does that to everyone. The thinks > everyone is as smart and energetic as he. > Think of him as like House. Sigh. Thanks for the backhanded defense, Roedy. What else might you have said about my post? Let's see, I answered the OP's question directly. I gave links that explained the basics of the relevant Java concepts. I pointed out alternatives that would accomplish the OP's stated goals. I made statements that were equivalent to what the other respondents said, e.g., that Java has its own rules and that C++ concepts don't apply. I never called the OP any names, not "troll" or anything else. Everything I said was directly relevant, answered the OP's question completely, and gave him a road to move forward. Now, isn't that what we're supposed to do? -- Lew
From: EJP on 18 Feb 2010 22:39 On 19/02/2010 6:43 AM, Johannes Schaub (litb) wrote: > I heard today that in Java you cannot override private methods. Correct. > I wonder why i can't write it like this. Because you can't override private methods. > I heard from people that do C++ that it is a good idea to make virtual > methods private That can't be right, otherwise nobody could call them. > What is the reason Java doesn't follow this path? I don't think anybody follows it.
From: Peter Duniho on 18 Feb 2010 23:48 EJP wrote: > [...] >> I heard from people that do C++ that it is a good idea to make virtual >> methods private > > That can't be right, otherwise nobody could call them. Of course they could. Private methods can be called from the class that declares them. Perhaps you meant "otherwise nobody could override them"? In the case of C++, that happens to not be correct either, but at least it's a more logical mistake to make. :) As far as the wisdom of making virtual methods private, that's debatable. In C++, a derived class can in fact override a private virtual method in a base class, so making the virtual method private doesn't cause a problem there. But the virtual method itself could only be called from the base class, or a class that overrides the method. As other languages prove so easily, there's nothing fundamentally wrong from a OO perspective with a virtual method being called from outside the class. I suppose someone might be worried about versioning problems, where some external client code is compiled against a specific version of a C++ library, and then the class definition changes for the library, shifting the vtable around. That doesn't come up, for example, in Java because everything's recompiled at run-time. But it's a theoretical risk for C++. Making the virtual method private ensures that calls via the vtable are done only by the code that will be guaranteed to be recompiled if the vtable changes. Client code would always access the virtual method via a delegating non-virtual method wrapper, and thus would be assured of dispatching the virtual method calls correctly. But, there are lots of scenarios where the client of the virtual method is guaranteed to be recompiled with the class containing the virtual method itself. A blanket rule to make virtual methods private is unnecessarily restrictive in that case. Also, since C++ functions can be inlined when declared in the header, a rule to always make virtual methods private has to go along with a rule to always put the wrapper function in the code file, not the header. Otherwise, calling the wrapper function doesn't actually guarantee that the call doesn't happen directly through the vtable. 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. Pete
From: Mike Schilling on 19 Feb 2010 00:30 "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. (Though it's a pattern with a specific set of use cases; as you'd probably guessed, :make all virtual mrhods private" is a pretty severe oversimplification.)
From: Peter Duniho on 19 Feb 2010 00:40
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. I understand the pattern. I don't get how the pattern is relevant in a discussion specifically about virtual methods. Pete |