I have a general idea on the differences between these 2 but would like more info. My anemic knowledge base of the 2 goes something like this... dynamic binding occurs at runtime and static occurs at compile time. I am trying to come up with examples. For example, is it correct to say polymorphism is an example of dynamic binding. What about casting - this can involve a possible runtime check. Does that mean that casting is an example of dynamic binding? Can I assume that static binding is when neither polymorphism (really a cast) nor casting occur? Does someone have a link that explains the 2 or fill in some more details. ThanKs!
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
I'm not sure I've ever considered static vs dynamic method binding in Java. Most of the time it has to be dynamic because the object we're working on could be the class we say it is or it could be any derived class (see Liskov Substitution Principle). We won't know until run time exactly what kind of object we have.
There might be exceptions. If we invoke a method or class that is final, the compiler might know that no subclass could override it and make a static reference to the method. Or if we create a class and call a method at the same time the compiler might be able to figureout the binding them.
Would such a thing be in the language spec for the compiler or up to the JVM implementor? And the really big question: Why would we ever care? [ July 30, 2003: Message edited by: Stan James ]
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Joined: Jul 11, 2001
Originally posted by Stan James: I'm not sure I've ever considered static vs dynamic method binding in Java. Most of the time it has to be dynamic because the object we're working on could be the class we say it is or it could be any derived class (see Liskov Substitution Principle). We won't know until run time exactly what kind of object we have.
That is true for instance methods. Class level (static) methods are statically bound in Java.
There might be exceptions. If we invoke a method or class that is final, the compiler might know that no subclass could override it and make a static reference to the method.
No, it can't - we could decide to replace the class file with a different one where the method isn't final.
Would such a thing be in the language spec for the compiler or up to the JVM implementor?
For the above reason, this can only be done at runtime. Suns Hotspot engine is doing this, for example. It is even able to do this for non-final methods when it knows that there isn't a subclass loaded yet!
Joined: Nov 04, 2001
hi Ilja i agree w/ u. why casting is any kind of binding??? actually, i was going to write that only but i might have got confused while putting it down after reading many similar things on net (googling) like - single/multiple dispatching , static/dynamic casting in Lisp , Java, C++ .... regards maulin
Joined: Jan 29, 2003
I haven't tried to get this low level for a long time. Do they still talk about V-Tables? Early in the C++ days there were huge debates about the overhead of building and searching tables of methods up and down the inheritance chain, and which compiler was doing it best. It was also debated that OO code would never perform well because code in different classes was likely to be in different memory pages and would force too much swapping. Implied in the first line above: There is no reason for business programmers to be worrying about this stuff is there? Mike Cowlishaw said writing the Rexx compiler was devilishly difficult, but he only had to do it once and the rest of us could stop worrying about that hard stuff for years to come. That's when I stopped worrying about it! It's still interesting to get a peek at the complexity compiler authors and JVM authors deal with, but only a curiosity to me.