Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #34233 > unrolled thread

When to use dynamic binding over dynamic dispatch?

Back to article view | Back to comp.lang.java.programmer

Contents

  When to use dynamic binding over dynamic dispatch? cdalten@gmail.com - 2016-05-02 18:08 -0700
    Re: When to use dynamic binding over dynamic dispatch? Sebastian <news@seyweiler.dyndns.org> - 2016-05-03 20:47 +0200
      Re: When to use dynamic binding over dynamic dispatch? Lew <lewbloch@gmail.com> - 2016-05-03 12:14 -0700
    Re: When to use dynamic binding over dynamic dispatch? Arne Vajhøj <arne@vajhoej.dk> - 2016-05-03 21:23 -0400
      Re: When to use dynamic binding over dynamic dispatch? Martin Gregorie <martin@address-in-sig.invalid> - 2016-05-04 10:48 +0000
      Re: When to use dynamic binding over dynamic dispatch? Robert Klemme <shortcutter@googlemail.com> - 2016-05-08 12:24 +0200
        Re: When to use dynamic binding over dynamic dispatch? Arne Vajhøj <arne@vajhoej.dk> - 2016-05-08 08:23 -0400
          Re: When to use dynamic binding over dynamic dispatch? Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-05-08 08:57 -0400
            Re: When to use dynamic binding over dynamic dispatch? Arne Vajhøj <arne@vajhoej.dk> - 2016-05-08 10:37 -0400
              Re: When to use dynamic binding over dynamic dispatch? Robert Klemme <shortcutter@googlemail.com> - 2016-05-08 22:30 +0200
                Re: When to use dynamic binding over dynamic dispatch? Arne Vajhøj <arne@vajhoej.dk> - 2016-05-08 23:08 -0400
                  Re: When to use dynamic binding over dynamic dispatch? Robert Klemme <shortcutter@googlemail.com> - 2016-05-09 08:16 +0200
              Re: When to use dynamic binding over dynamic dispatch? Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-05-08 16:44 -0400
                Re: When to use dynamic binding over dynamic dispatch? Arne Vajhøj <arne@vajhoej.dk> - 2016-05-08 23:16 -0400
                  Re: When to use dynamic binding over dynamic dispatch? Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-05-09 00:39 -0400

#34233 — When to use dynamic binding over dynamic dispatch?

From what I understand, dynamic binding implies dynamic dispatch. So the question is, when do you use one over the other?

[toc] | [next] | [standalone]

#34236

Am 03.05.2016 03:08, schrieb cdalten@gmail.com:
>  From what I understand, dynamic binding implies dynamic dispatch. So the question is, when do you use one over the other?
>
Sounds a bit like an interview question, or homework.

You do not usually "use" one or the other at all. These things get 
decided for you by the JVM (the Java runtime) and the Java compiler.
You should look at how these two interact, and when it is decided what 
variable names and method calls mean for

private, final and static methods and variables
abstract resp. overridden methods
overloaded methods
etc.

The compile time type of a reference variable and the runtime type of an 
object are not necessarily the same, and different decisions are based 
on each.

Read a good book. I suppose the topic is really too large and the 
question too imprecise for a newsgroup posting.

-- Sebastian

[toc] | [prev] | [next] | [standalone]

#34237

You use dynamic binding simply by having a heritable method. You use static binding by making a method non-heritable, which should be your preference. The decision is properly made only for the sake of the object model, not over some weakly-imagined assessment of which kind of binding implements your decision. In practice what the JVM does with it is none of your concern. It will optimize where it needs to.

[toc] | [prev] | [next] | [standalone]

#34238

On 5/2/2016 9:08 PM, cdalten@gmail.com wrote:
> From what I understand, dynamic binding implies dynamic dispatch. So the question is, when do you use one over the other?

As other have already pointed put then these terms are not well defined
for Java.

But if we use common programming definitions then:

dynamic binding = lookup of method by name at runtime
dynamic dispatch = virtual methods polymorphism

Java does not have real language support for dynamic binding (with
the definition above). It is only possible via reflection.

All methods unless declared static or final are virtual in Java,
so dynamic dispatch is used all the time.

I can not think of any situation where I would have a natural
choice between the two (with the above definition).

Sometimes an alternate definition is used for dynamic binding:

dynamic binding = synonym for dynamic dispatch

But the question does not make much sense with that definition
either.

Arne

[toc] | [prev] | [next] | [standalone]

#34242

On Tue, 03 May 2016 21:23:07 -0400, Arne Vajhøj wrote:

> dynamic binding = lookup of method by name at runtime 
> dynamic dispatch = virtual methods polymorphism
> 
> Java does not have real language support for dynamic binding (with the
> definition above). It is only possible via reflection.
>
I think the closest we can come is explicit use of a ClassLoader 
extension to force a specified subclass to be loaded. 

This is really no different from using the dynamic linking loader in a C 
program to load plugins from a library file: in both cases linking is 
dynamic, because its under the control of the running process, but 
dispatch isn't because the loader has fixed up the method or function 
references at load time.  


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#34262

On 04.05.2016 03:23, Arne Vajhøj 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.  Methods declared 
"private" are not.

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#34264

On 5/8/2016 6:24 AM, Robert Klemme wrote:
> On 04.05.2016 03:23, Arne Vajhøj 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 = method that can be overridden
final method = method that can not be overridden

then how can it be?

>  Methods declared "private" are not.

True.

Arne

[toc] | [prev] | [next] | [standalone]

#34265

On 5/8/2016 8:23 AM, Arne Vajhøj wrote:
> On 5/8/2016 6:24 AM, Robert Klemme wrote:
>> On 04.05.2016 03:23, Arne Vajhøj 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 = method that can be overridden
> final method = 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 = new Sub();
	obj.method();


-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#34266

On 5/8/2016 8:57 AM, Eric Sosman wrote:
> On 5/8/2016 8:23 AM, Arne Vajhøj wrote:
>> On 5/8/2016 6:24 AM, Robert Klemme wrote:
>>> On 04.05.2016 03:23, Arne Vajhøj 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 = method that can be overridden
>> final method = 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 = new Sub();
>     obj.method();

As a starting point I would not call Sub.method
a virtual method due to above definition.

But per JLS such calls are "invocation mode virtual".

<quote>
The invocation mode, computed as follows:

     If the qualifying type of the method declaration is a class, then:

         If the compile-time declaration has the static modifier, then 
the invocation mode is static.

         Otherwise, if the compile-time declaration has the private 
modifier, then the invocation mode is nonvirtual.

         Otherwise, if the part of the method invocation before the left 
parenthesis is of the form super . Identifier or of the form TypeName . 
super . Identifier, then the invocation mode is super.

         Otherwise, the invocation mode is virtual.

     If the qualifying type of the method invocation is an interface, 
then the invocation mode is interface.
</quote>

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.

You don't even have to override a method to make it invocation
mode virtual.

So even:

public class Funny {
     public final void m() {
         System.out.println("I am funny");
     }
     public static void main(String[] args) {
         Funny o = new Funny();
         o.m();
     }
}

result in:

  9: invokevirtual #7                  // Method m:()V

Well ...

Arne

[toc] | [prev] | [next] | [standalone]

#34267

On 08.05.2016 16:37, Arne Vajhøj wrote:
> On 5/8/2016 8:57 AM, Eric Sosman wrote:
>> On 5/8/2016 8:23 AM, Arne Vajhøj wrote:
>>> On 5/8/2016 6:24 AM, Robert Klemme wrote:
>>>> On 04.05.2016 03:23, Arne Vajhøj 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 = method that can be overridden
>>> final method = 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 = 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 method 
uses dynamic dispatch (late binding) as described in Wikipedia:
https://en.wikipedia.org/wiki/Virtual_method

> 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 instead 
focuses on invocation semantics.

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#34269

On 5/8/2016 4:30 PM, Robert Klemme wrote:
> On 08.05.2016 16:37, Arne Vajhøj wrote:
>> On 5/8/2016 8:57 AM, Eric Sosman wrote:
>>> On 5/8/2016 8:23 AM, Arne Vajhøj wrote:
>>>> On 5/8/2016 6:24 AM, Robert Klemme wrote:
>>>>> On 04.05.2016 03:23, Arne Vajhøj 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 = method that can be overridden
>>>> final method = 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 = 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 method
> 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 ...

>> 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 instead
> 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 = 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.

Arne

[toc] | [prev] | [next] | [standalone]

#34272

On 09.05.2016 05:08, Arne Vajhøj wrote:
> On 5/8/2016 4:30 PM, Robert Klemme wrote:
>> On 08.05.2016 16:37, Arne Vajhøj wrote:
>>> On 5/8/2016 8:57 AM, Eric Sosman wrote:
>>>> On 5/8/2016 8:23 AM, Arne Vajhøj wrote:
>>>>> On 5/8/2016 6:24 AM, Robert Klemme wrote:
>>>>>> On 04.05.2016 03:23, Arne Vajhøj 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 = method that can be overridden
>>>>> final method = 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 = 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 method
>> 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 
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 
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 
dispatch is facilitated."

Now, given the remainder of the article I believe the only valid 
interpretation in this context is the second one.  This is also 
suggested by the "a virtual function or virtual method" which indicates 
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 instead
>> 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 = 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 
instruction to the compiler to not compile a method with the same 
signature in classes inheriting from the class owning the final method. 
  (Additionally the JVM will verify on class load that this constraint 
holds.)

"virtual" describes a technique of method dispatch also commonly called 
"late binding".  It means the method to call is determined at runtime 
vs. at compile time for non virtual methods.  You can also have a 
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 
a method is declared "virtual" or not.

In Java virtual method invocation is the default and only static and 
private methods are the exceptions.  I use "virtual" in the conceptual 
sense including "invokevirtual" and "invokeinterface" because both 
employ late binding.


Can you provide more background how you got to this definition you are 
using?

virtual method = method that can be overridden

Kind regards

	robert

[1] https://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Final_Class


-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#34268

On 5/8/2016 10:37 AM, Arne Vajhøj wrote:
> On 5/8/2016 8:57 AM, Eric Sosman wrote:
>> On 5/8/2016 8:23 AM, Arne Vajhøj wrote:
>>> On 5/8/2016 6:24 AM, Robert Klemme wrote:
>>>> On 04.05.2016 03:23, Arne Vajhøj 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 = method that can be overridden
>>> final method = method that can not be overridden

     Why is this a "given?"  Who gave it?

>>> then how can it be?
>>
>>     class Super {
>>         public void method() {}
>>     }
>>
>>     class Sub extends Super {
>>         public final void method() {}
>>     }
>>
>>     ...
>>
>>     Super obj = new Sub();
>>     obj.method();
>
> As a starting point I would not call Sub.method
> a virtual method due to above definition.

     Let's try another example, if you dislike my first one:

	class Worker implements Runnable {
	    @Override
	    public final void run() {}
	}

The Worker#run method is quite obviously final, and not
overridable.  Do you maintain that it isn't virtual?  If
we follow the above with

	new Thread(new Worker()).start();

... should the thread's invocation of Worker#run use something
other than virtual invocation?

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#34270

On 5/8/2016 4:44 PM, Eric Sosman wrote:
> On 5/8/2016 10:37 AM, Arne Vajhøj wrote:
>> On 5/8/2016 8:57 AM, Eric Sosman wrote:
>>> On 5/8/2016 8:23 AM, Arne Vajhøj wrote:
>>>> then how can it be?
>>>
>>>     class Super {
>>>         public void method() {}
>>>     }
>>>
>>>     class Sub extends Super {
>>>         public final void method() {}
>>>     }
>>>
>>>     ...
>>>
>>>     Super obj = new Sub();
>>>     obj.method();
>>
>> As a starting point I would not call Sub.method
>> a virtual method due to above definition.
>
>     Let's try another example, if you dislike my first one:
>
>     class Worker implements Runnable {
>         @Override
>         public final void run() {}
>     }
>
> The Worker#run method is quite obviously final, and not
> overridable.  Do you maintain that it isn't virtual?  If
> we follow the above with
>
>     new Thread(new Worker()).start();
>
> ... should the thread's invocation of Worker#run use something
> other than virtual invocation?

It certainly need to use virtual invocation, because it is
calling Runnable run which is virtual.

But does that make Worker run virtual when it is final?

Seems to be the Java way. But not natural to me.

Arne

PS: I don't think the above will use virtual invocation - it will
     use interface invocation as Runnable is an interface. But
     I don't think that is particular relevant.

[toc] | [prev] | [next] | [standalone]

#34271

On 5/8/2016 11:16 PM, Arne Vajhøj wrote:
> On 5/8/2016 4:44 PM, Eric Sosman wrote:
>>[...]
>>     Let's try another example, if you dislike my first one:
>>
>>     class Worker implements Runnable {
>>         @Override
>>         public final void run() {}
>>     }
>> [...]
> PS: I don't think the above will use virtual invocation - it will
>     use interface invocation as Runnable is an interface. But
>     I don't think that is particular relevant.

     <facepalm> Oops! </facepalm>

     You're right: The invocation mode is `interface', not `virtual'.
I should have stopped with my first example, and left well enough
alone.

     To the wider issue, though: It seems you are unhappy because you
and Java have different notions of what "virtual" means.  You wrote
earlier,

 >>> virtual method = method that can be overridden
 >>> final method = method that can not be overridden

... and while this might be a perfectly good definition, it is not
Java's definition.  The choice, then, is up to you: Stick with your
definition and remain miserable, or reconcile yourself with Java's
and become joyous and carefree.  :)

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web