Path: csiph.com!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Robert Klemme Newsgroups: comp.lang.java.programmer Subject: Re: When to use dynamic binding over dynamic dispatch? Date: Mon, 9 May 2016 08:16:02 +0200 Lines: 134 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: individual.net OxIL4F4iBQPkkppSnuWJiAY0+w+tL/urClju+h2Xq5kCje8t8= Cancel-Lock: sha1:oCExNZOekRnZr+vDllF3gT16uek= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 In-Reply-To: Xref: csiph.com comp.lang.java.programmer:34272 On 09.05.2016 05:08, Arne Vajh=C3=B8j wrote: > On 5/8/2016 4:30 PM, Robert Klemme wrote: >> On 08.05.2016 16:37, Arne Vajh=C3=B8j wrote: >>> On 5/8/2016 8:57 AM, Eric Sosman wrote: >>>> On 5/8/2016 8:23 AM, Arne Vajh=C3=B8j wrote: >>>>> On 5/8/2016 6:24 AM, Robert Klemme wrote: >>>>>> On 04.05.2016 03:23, Arne Vajh=C3=B8j wrote: >>>>>>> All methods unless declared static or final are virtual in Java, >>>>>>> so dynamic dispatch is used all the time. >>>>>> >>>>>> Methods declared as "final" are virtual as well. >>>>> >>>>> Given that: >>>>> >>>>> virtual method =3D method that can be overridden >>>>> final method =3D method that can not be overridden >>>>> >>>>> then how can it be? >>>> >>>> class Super { >>>> public void method() {} >>>> } >>>> >>>> class Sub extends Super { >>>> public final void method() {} >>>> } >>>> >>>> ... >>>> >>>> Super obj =3D new Sub(); >>>> obj.method(); >>> >>> As a starting point I would not call Sub.method >>> a virtual method due to above definition. >> >> That seems to me a fairly uncommon definition. For me a virtual metho= d >> uses dynamic dispatch (late binding) as described in Wikipedia: >> https://en.wikipedia.org/wiki/Virtual_method > > Well - it is actually mentioned as one possibility in the link > you provide so ... I had thought so for a brief moment, too, but now I do not. The point=20 is, the sentence is ambiguous. Here are two ways you can understand it: "In object-oriented programming, a virtual function or virtual method is = ( an inheritable and overridable function ) or ( method for which=20 dynamic dispatch is facilitated )." "In object-oriented programming, a virtual function or virtual method is = an inheritable and overridable ( function or method ) for which dynamic=20 dispatch is facilitated." Now, given the remainder of the article I believe the only valid=20 interpretation in this context is the second one. This is also=20 suggested by the "a virtual function or virtual method" which indicates=20 that the definition is intended for functions and methods as well. >>> But per JLS such calls are "invocation mode virtual". >> >> Hence it's a virtual method in my book. >> >>> If we make the logical conclusion that methods that will be called >>> with invocation mode virtual are virtual methods, then the definition= >>> of virtual methods is certainly different in Java. >> >> Certainly different from the definition you offered above. Ironically= >> your first statement matches the definition of "virtual method" that I= >> have in mind much better because it speaks of "dynamic dispatch", i.e.= >> does not make a statement about whether it can be overridden and inste= ad >> focuses on invocation semantics. > > I just find it very difficult to see: > > public class Funny { > public final void m() { > System.out.println("I am funny"); > } > public static void main(String[] args) { > Funny o =3D new Funny(); > o.m(); > } > } > > as a virtual method. And there is no need for dynamic dispatch. > Java just uses the same instruction as when dynamic dispatch > is needed. "final" and "virtual" are two orthogonal concepts: "final" is an=20 instruction to the compiler to not compile a method with the same=20 signature in classes inheriting from the class owning the final method.=20 (Additionally the JVM will verify on class load that this constraint=20 holds.) "virtual" describes a technique of method dispatch also commonly called=20 "late binding". It means the method to call is determined at runtime=20 vs. at compile time for non virtual methods. You can also have a=20 virtual method in C++ in a class declared "final" (since C++11, see [1]) = which effectively renders all methods unoverridable. I mention C++ here = because there it actually makes a difference for the invocation whether=20 a method is declared "virtual" or not. In Java virtual method invocation is the default and only static and=20 private methods are the exceptions. I use "virtual" in the conceptual=20 sense including "invokevirtual" and "invokeinterface" because both=20 employ late binding. Can you provide more background how you got to this definition you are=20 using? virtual method =3D method that can be overridden Kind regards robert [1] https://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Final_Class --=20 remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/