why are overloaded methods statically bound?

Discussion in 'Java' started by sticky@texas.net, Oct 29, 2003.

  1. Guest

    Hello all,

    Anyone know why aren't overloaded methods dynamically bound, like
    overridden methods? My guess at this point is that having both be
    dynamically bound might create paradoxes, but that's a wild guess. It
    does seem like if it were possible, it would have been better if they
    were both the same, both dynamically bound.

    TIA
    -aline
     
    , Oct 29, 2003
    #1
    1. Advertising

  2. Dale King Guest

    <> wrote in message
    news:...
    > Hello all,
    >
    > Anyone know why aren't overloaded methods dynamically bound, like
    > overridden methods? My guess at this point is that having both be
    > dynamically bound might create paradoxes, but that's a wild guess. It
    > does seem like if it were possible, it would have been better if they
    > were both the same, both dynamically bound.



    I'm not sure if paradox is the word I would use, but you certainly end up
    with ambiguous situations. Imagine if you had methods:

    void method( Object o ) { ... }
    void method( InterfaceA a ) { ... }
    void method( InterfaceB a ) { ... }

    Object o = new ClassThatImplementsInterfaceAandB()

    If I call the method with o which method is supposed to be called?

    The problem grows exponentially as the number of parameters is increased.

    The other problem is performance. It would be quite a performance hit and
    quite the hard task to have to examine the types of the arguments and search
    for the correct method to call. On the contrary, the dynamic binding of
    overridden methods is fast and easy.
    --
    Dale King
     
    Dale King, Oct 29, 2003
    #2
    1. Advertising

  3. Dale King <> coughed up the following:

    > <> wrote in message
    > news:...
    >> Hello all,
    >>
    >> Anyone know why aren't overloaded methods dynamically bound, like
    >> overridden methods? My guess at this point is that having both be
    >> dynamically bound might create paradoxes, but that's a wild guess. It
    >> does seem like if it were possible, it would have been better if they
    >> were both the same, both dynamically bound.

    >
    >
    > I'm not sure if paradox is the word I would use, but you certainly
    > end up with ambiguous situations. Imagine if you had methods:
    >
    > void method( Object o ) { ... }
    > void method( InterfaceA a ) { ... }
    > void method( InterfaceB a ) { ... }
    >
    > Object o = new ClassThatImplementsInterfaceAandB()
    >
    > If I call the method with o which method is supposed to be called?


    Javac will actually prompt you with an error asking you to specifically cast
    the actual parameter so it knows:

    method((Object)o);
    method((InterfaceA)o);
    method((InterfaceB)0);
     
    Thomas G. Marshall, Oct 29, 2003
    #3
  4. Dale King <> scribbled the following:
    > <> wrote in message
    > news:...
    >> Hello all,
    >>
    >> Anyone know why aren't overloaded methods dynamically bound, like
    >> overridden methods? My guess at this point is that having both be
    >> dynamically bound might create paradoxes, but that's a wild guess. It
    >> does seem like if it were possible, it would have been better if they
    >> were both the same, both dynamically bound.


    > I'm not sure if paradox is the word I would use, but you certainly end up
    > with ambiguous situations. Imagine if you had methods:


    > void method( Object o ) { ... }
    > void method( InterfaceA a ) { ... }
    > void method( InterfaceB a ) { ... }


    > Object o = new ClassThatImplementsInterfaceAandB()


    > If I call the method with o which method is supposed to be called?


    > The problem grows exponentially as the number of parameters is increased.


    You don't need interfaces.

    void method(Object a, Object b, Object c, Object d, Object e) { ... }
    void method(Object a, Object b, Object c, Object d, String e) { ... }
    void method(Object a, Object b, Object c, String d, Object e) { ... }
    void method(Object a, Object b, Object c, String d, String e) { ... }
    /* and so on... */
    void method(String a, String b, String c, String d, String e) { ... }
    /* that is, 32 overloaded methods */

    method(null, null, null, null, null);

    Now which of the 32 versions is the JVM supposed to pick?

    --
    /-- Joona Palaste () ------------- Finland --------\
    \-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
    "Ice cream sales somehow cause drownings: both happen in summer."
    - Antti Voipio & Arto Wikla
     
    Joona I Palaste, Oct 29, 2003
    #4
  5. Thomas G. Marshall <> scribbled the following:
    > Dale King <> coughed up the following:
    >> <> wrote in message
    >> news:...
    >>> Hello all,
    >>>
    >>> Anyone know why aren't overloaded methods dynamically bound, like
    >>> overridden methods? My guess at this point is that having both be
    >>> dynamically bound might create paradoxes, but that's a wild guess. It
    >>> does seem like if it were possible, it would have been better if they
    >>> were both the same, both dynamically bound.

    >>
    >> I'm not sure if paradox is the word I would use, but you certainly
    >> end up with ambiguous situations. Imagine if you had methods:
    >>
    >> void method( Object o ) { ... }
    >> void method( InterfaceA a ) { ... }
    >> void method( InterfaceB a ) { ... }
    >>
    >> Object o = new ClassThatImplementsInterfaceAandB()
    >>
    >> If I call the method with o which method is supposed to be called?


    > Javac will actually prompt you with an error asking you to specifically cast
    > the actual parameter so it knows:


    > method((Object)o);
    > method((InterfaceA)o);
    > method((InterfaceB)0);


    Well yes it does, but that's *precisely* because they are statically
    bound. If they were dynamically bound javac wouldn't be able to do squat.

    --
    /-- Joona Palaste () ------------- Finland --------\
    \-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
    "Products like that make me wish I could menstruate."
    - Andy Richter
     
    Joona I Palaste, Oct 29, 2003
    #5
  6. Thomas G. Marshall <>
    coughed up the following:

    > Dale King <> coughed up the following:
    >
    >> <> wrote in message
    >> news:...
    >>> Hello all,
    >>>
    >>> Anyone know why aren't overloaded methods dynamically bound, like
    >>> overridden methods? My guess at this point is that having both be
    >>> dynamically bound might create paradoxes, but that's a wild guess.
    >>> It does seem like if it were possible, it would have been better if
    >>> they were both the same, both dynamically bound.

    >>
    >>
    >> I'm not sure if paradox is the word I would use, but you certainly
    >> end up with ambiguous situations. Imagine if you had methods:
    >>
    >> void method( Object o ) { ... }
    >> void method( InterfaceA a ) { ... }
    >> void method( InterfaceB a ) { ... }
    >>
    >> Object o = new ClassThatImplementsInterfaceAandB()
    >>
    >> If I call the method with o which method is supposed to be called?

    >
    > Javac will actually prompt you with an error asking you to
    > specifically cast the actual parameter so it knows:
    >
    > method((Object)o);
    > method((InterfaceA)o);
    > method((InterfaceB)0);


    Clarification. I don't really remember what javac does.

    The old visual cafe for java compiler used to do precisely that. I just
    figured that it was part of the jls.

    And I'm crummy at finding things in the jls---and I cannot find it.
     
    Thomas G. Marshall, Oct 29, 2003
    #6
  7. Thomas G. Marshall wrote:

    > Javac will actually prompt you with an error asking you to specifically cast
    > the actual parameter so it knows:
    >
    > method((Object)o);
    > method((InterfaceA)o);
    > method((InterfaceB)0);


    But that was Dale's *point*, wasn't it? Static binding ensures that the compiler
    can force you to resolve such ambiguities. To use dynamic binding, they would either
    have to be resolved through arbitrary rules (causing confusing behaviour of
    the code) or through runtime exceptions (causing crashes).
     
    Michael Borgwardt, Oct 29, 2003
    #7
  8. Michael Borgwardt <> coughed up the following:

    > Thomas G. Marshall wrote:
    >
    >> Javac will actually prompt you with an error asking you to
    >> specifically cast
    >> the actual parameter so it knows:
    >>
    >> method((Object)o);
    >> method((InterfaceA)o);
    >> method((InterfaceB)0);

    >
    > But that was Dale's *point*, wasn't it? Static binding ensures that
    > the compiler can force you to resolve such ambiguities. To use
    > dynamic binding, they would either have to be resolved through
    > arbitrary rules (causing confusing behaviour of
    > the code) or through runtime exceptions (causing crashes).


    Yep. My apologies.
     
    Thomas G. Marshall, Oct 29, 2003
    #8
  9. "Dale King" <> wrote in message news:<>...
    > <> wrote in message
    > news:...
    > > Hello all,
    > >
    > > Anyone know why aren't overloaded methods dynamically bound, like
    > > overridden methods? My guess at this point is that having both be
    > > dynamically bound might create paradoxes, but that's a wild guess. It
    > > does seem like if it were possible, it would have been better if they
    > > were both the same, both dynamically bound.

    >
    >
    > I'm not sure if paradox is the word I would use, but you certainly end up
    > with ambiguous situations. Imagine if you had methods:
    >
    > void method( Object o ) { ... }
    > void method( InterfaceA a ) { ... }
    > void method( InterfaceB a ) { ... }
    >
    > Object o = new ClassThatImplementsInterfaceAandB()
    >
    > If I call the method with o which method is supposed to be called?


    This can be handled if the language designers so choose. Common Lisp
    and Dylan and probably others define precedence rules to resolve all
    ambiguities, using information such as what order you specified A and
    B when defining the new class.

    > The problem grows exponentially as the number of parameters is increased.
    >
    > The other problem is performance. It would be quite a performance hit and
    > quite the hard task to have to examine the types of the arguments and search
    > for the correct method to call. On the contrary, the dynamic binding of
    > overridden methods is fast and easy.


    Again, if the language designers want to support this, there are
    techniques for constructing pretty fast table lookups. Common Lisp
    implementors have to work extra hard since new classes can be defined
    at any time.
     
    Chris Riesbeck, Oct 29, 2003
    #9
  10. Joona I Palaste wrote:

    > Thomas G. Marshall <> scribbled the following:
    >>Javac will actually prompt you with an error asking you to specifically cast
    >>the actual parameter so it knows:

    >
    >
    >> method((Object)o);
    >> method((InterfaceA)o);
    >> method((InterfaceB)0);

    >
    >
    > Well yes it does, but that's *precisely* because they are statically
    > bound. If they were dynamically bound javac wouldn't be able to do squat.


    Yes, and then the ambiguity would manifest at runtime. Rules to choose
    one method over the others could be applied, but no such rule set could
    be expected to reliably choose the right one. Much better to detect the
    problem at compile time and make the programmer fix it.


    John Bollinger
     
    John C. Bollinger, Oct 29, 2003
    #10
  11. Chris Smith Guest

    Chris Riesbeck wrote:
    > > The other problem is performance. It would be quite a performance hit and
    > > quite the hard task to have to examine the types of the arguments and search
    > > for the correct method to call. On the contrary, the dynamic binding of
    > > overridden methods is fast and easy.

    >
    > Again, if the language designers want to support this, there are
    > techniques for constructing pretty fast table lookups. Common Lisp
    > implementors have to work extra hard since new classes can be defined
    > at any time.


    But wait: that's also true of Java! I doubt Common Lisp or this
    hypothetical language called Java-With-Dynamic-Binding-On-Parameters
    could match (or even come close to) existing polymorphism, on the
    message recipient only, when looking up method dispatch based on
    parameter object classes.

    --
    www.designacourse.com
    The Easiest Way to Train Anyone... Anywhere.

    Chris Smith - Lead Software Developer/Technical Trainer
    MindIQ Corporation
     
    Chris Smith, Oct 30, 2003
    #11
  12. Chris Smith Guest

    Thomas G. Marshall wrote:
    >
    > And I'm crummy at finding things in the jls---and I cannot find it.


    If anyone is looking, it's the latter part of section 15.12.2.2 ("Choose
    the Most Specific Method"), with an example provided in 15.12.2.3
    ("Example: Overloading Ambiguity").

    --
    www.designacourse.com
    The Easiest Way to Train Anyone... Anywhere.

    Chris Smith - Lead Software Developer/Technical Trainer
    MindIQ Corporation
     
    Chris Smith, Oct 30, 2003
    #12
  13. Chris Smith <> wrote in message news:<4.net>...
    > Chris Riesbeck wrote:
    > > > The other problem is performance. It would be quite a performance hit and
    > > > quite the hard task to have to examine the types of the arguments and search
    > > > for the correct method to call. On the contrary, the dynamic binding of
    > > > overridden methods is fast and easy.

    > >
    > > Again, if the language designers want to support this, there are
    > > techniques for constructing pretty fast table lookups. Common Lisp
    > > implementors have to work extra hard since new classes can be defined
    > > at any time.

    >
    > But wait: that's also true of Java! I doubt Common Lisp or this
    > hypothetical language called Java-With-Dynamic-Binding-On-Parameters
    > could match (or even come close to) existing polymorphism, on the
    > message recipient only, when looking up method dispatch based on
    > parameter object classes.


    Sorry, I didn't understand your first sentence at all. *What's* also
    true of Java?

    And I'm not sure what you meant by "match existing polymorphism." Do
    you mean performance? If so, I didn't say it did. I said "pretty
    fast." It's fast enough for tons of Lisp applications doing graphics
    and web servers and so on. But multi-method dispatch is going to cost
    something, just like method dispatch costs, compared to a C function
    call. It's a tradeoff -- speed for programming flexibility. Java is
    one valid set of trade offs, C++ another, Lisp another.
     
    Chris Riesbeck, Oct 30, 2003
    #13
  14. Michael Borgwardt <> wrote in message news:<bnoppc$13b99g$-berlin.de>...
    > Thomas G. Marshall wrote:
    >
    > > Javac will actually prompt you with an error asking you to specifically cast
    > > the actual parameter so it knows:
    > >
    > > method((Object)o);
    > > method((InterfaceA)o);
    > > method((InterfaceB)0);

    >
    > But that was Dale's *point*, wasn't it? Static binding ensures that the compiler
    > can force you to resolve such ambiguities. To use dynamic binding, they would either
    > have to be resolved through arbitrary rules (causing confusing behaviour of
    > the code) or through runtime exceptions (causing crashes).


    Whether the behavior is confusing depends on the rules. I've never
    been confused by Lisp's method dispatch resolution rules. I've been
    frequently confused by C++'s when lookup interacts with namespaces.
    But each language, Java included, gives me certain features in
    exchange for its confusing aspects.
     
    Chris Riesbeck, Oct 30, 2003
    #14
  15. Chris Smith Guest

    Chris Riesbeck wrote:
    > Sorry, I didn't understand your first sentence at all. *What's* also
    > true of Java?


    That new classes can be defined at any time.

    > And I'm not sure what you meant by "match existing polymorphism." Do
    > you mean performance? If so, I didn't say it did. I said "pretty
    > fast."


    Okay, then we don't disagree.

    Nevertheless, it seemed appropriate to point out that this isn't just a
    "the language designers didn't care enough" kind of situation that your
    post suggested it was. There are valid reasons why even a good
    implementation of a language with parameter-based polymorphism would
    have weaknesses compared to a language without it; and both the
    difficulty of predicting dispatch with that many factors involved and
    the very real performance issues (which extend beyond the language
    designer not being clever enough) are valid reasons that have been
    mentioned in this thread.

    --
    www.designacourse.com
    The Easiest Way to Train Anyone... Anywhere.

    Chris Smith - Lead Software Developer/Technical Trainer
    MindIQ Corporation
     
    Chris Smith, Oct 31, 2003
    #15
  16. Chris Smith <> wrote in message news:<4.net>...
    >
    > > And I'm not sure what you meant by "match existing polymorphism." Do
    > > you mean performance? If so, I didn't say it did. I said "pretty
    > > fast."

    >
    > Okay, then we don't disagree.
    >
    > Nevertheless, it seemed appropriate to point out that this isn't just a
    > "the language designers didn't care enough" kind of situation that your
    > post suggested it was.


    My post said "This can be handled if the language designers so
    choose." and "Again, if the language designers want to support
    this,..."

    How does that turn into "the language designers didn't care enough?"

    > There are valid reasons why even a good
    > implementation of a language with parameter-based polymorphism would
    > have weaknesses compared to a language without it;


    and strengths. If it was all weaknesses, no one would do it. If it was
    all strengths, no one would not do it.

    > and both the
    > difficulty of predicting dispatch with that many factors involved


    What's your evidence for this? It's messy in C++ because namespaces
    are involved. But I've not seen any results that show programmers in
    the Common Lisp Object System (CLOS) have any trouble here with normal
    programming.

    > and
    > the very real performance issues (which extend beyond the language
    > designer not being clever enough) are valid reasons that have been
    > mentioned in this thread.


    No one gave any performance metrics here or cited any "very real
    performance measures." Googling for "multimethod dispatch performance"
    finds a number of results such as constant-time lookup for Cecil, and
    modest to no penalty for an multimethod extension to Java, and that
    was in the first few search results.

    A key result in the Java article is that doing multimethod dispatch by
    hand, which is what programmers have to do currently, writing
    instanceof calls, is SLOWER by a wide margin that what a compiler can
    do with multimethods supported.

    Cecil: http://portal.acm.org/citation.cfm?doid=271510.271521

    Java: http://citeseer.nj.nec.com/dutchyn01multidispatch.html

    And just to make it clear: I'm not saying Lisp is better than Java,
    and I'm not saying Java should have multimethod dispatch. I'm simply
    trying to point out that things aren't as black and white about the
    complexity and performance tradeoffs as some of the postings have
    suggested. There are perfectly usable languages that have made
    decisions differently than the Java designers did.
     
    Chris Riesbeck, Oct 31, 2003
    #16
  17. Chris Smith Guest

    Chris Riesbeck wrote:
    > My post said "This can be handled if the language designers so
    > choose." and "Again, if the language designers want to support
    > this,..."
    >
    > How does that turn into "the language designers didn't care enough?"


    Okay, let's put this in context. Original poster asks why Java doesn't
    base polymorphism on parameter types. Someone responds saying
    performance. You respond saying "this can be handled if the language
    designers so choose." So, what you said is that the performance impact
    is solvable, and there's some *other* reason for the choice instead.
    You may not have meant to say that, but you clearly did.

    I objected, and you made some statement about "different trade-offs" and
    "fast enough" to imply that you were minimizing the importance of
    performance. I agreed that this is sometimes the case.

    The "didn't care enough" was hyperbole on my part. You haven't said
    what other reasons you believed the language designers to have in
    omitting the feature, if indeed you believe it to be the case.

    > > There are valid reasons why even a good
    > > implementation of a language with parameter-based polymorphism would
    > > have weaknesses compared to a language without it;

    >
    > and strengths. If it was all weaknesses, no one would do it. If it was
    > all strengths, no one would not do it.


    Of course! That's not the issue. The issue is that when someone
    pointed out the weaknesses, you jumped in and and said "that can be
    handled" as if it weren't an issue.

    > > and both the
    > > difficulty of predicting dispatch with that many factors involved

    >
    > What's your evidence for this? It's messy in C++ because namespaces
    > are involved. But I've not seen any results that show programmers in
    > the Common Lisp Object System (CLOS) have any trouble here with normal
    > programming.


    Messy in C++? It doesn't even exist in C++! The difficulty in
    predicting method dispatch on so many factors is explained merely by the
    observation that there are so many more factors involved. That
    implicitly makes it harder to predict. Frankly, I think the amount of
    difficulty people have with just static resolution of overloaded
    parameter types indicates great trouble in that direction.

    I don't know anything about CLOS programmers, so I can't speak one way
    or the other about whether they are confused. I can only point out that
    there is a much longer and more complex process involved than is
    generally the case.

    > No one gave any performance metrics here or cited any "very real
    > performance measures." Googling for "multimethod dispatch performance"
    > finds a number of results such as constant-time lookup for Cecil, and
    > modest to no penalty for an multimethod extension to Java, and that
    > was in the first few search results.


    It would take a good bit more effort than USENET is worth for someone to
    put together a comparative benchmark of performance between a real
    language and a hypothetical language.

    You provide a pseudo-comparison in which the authors compare the
    techniques using a worst case scenario piece of code, and even then
    conspicuously avoid quoting results of the original code running on an
    unaltered modern virtual machine using standard JVM performance
    techniques. Instead, they represent "normal" with an interpreted VM; a
    meaningless number, as we all know. Furthermore, even this paper making
    the case for such method dispatch in Java doesn't dare apply it
    universally. Instead, they mark a few very specific places to use the
    technique using a marker interface, recognizing that it's not
    universally applicable.

    (As for constant time, I should certainly hope that method dispatch is
    constant time! That's generally considered a basic assumption in
    programming languages, not an accomplishment. The challenges in
    practical optimization of language implementations relate to minimizing
    the cache touches of the process and thus chance of a page fault, the
    plain processor cycles involved, etc.)

    I'm all for giving something a fair shot, but I think you're
    misrepresenting the issue by claiming that general polymorphism on
    parameters in Java might possibly not have a performance impact.

    --
    www.designacourse.com
    The Easiest Way to Train Anyone... Anywhere.

    Chris Smith - Lead Software Developer/Technical Trainer
    MindIQ Corporation
     
    Chris Smith, Oct 31, 2003
    #17
  18. Chris Smith <> wrote in message news:<4.net>...
    > Chris Riesbeck wrote:
    > > My post said "This can be handled if the language designers so
    > > choose." and "Again, if the language designers want to support
    > > this,..."
    > >
    > > How does that turn into "the language designers didn't care enough?"

    >
    > Okay, let's put this in context. Original poster asks why Java doesn't
    > base polymorphism on parameter types. Someone responds saying
    > performance. You respond saying "this can be handled if the language
    > designers so choose."


    That's not the correct context.

    My posting was in response to Dale King's comment about ambiguous
    method calls, the one that started with "I'm not sure if paradox is
    the word I would use, but you certainly end up with ambiguous
    situations. Imagine if you had methods:..."

    I was pointing out that his example is only ambiguous if the language
    designers don't define a resolution rule. They didn't in C++, they did
    in CLOS.


    > > No one gave any performance metrics here or cited any "very real
    > > performance measures." Googling for "multimethod dispatch performance"
    > > finds a number of results such as constant-time lookup for Cecil, and
    > > modest to no penalty for an multimethod extension to Java, and that
    > > was in the first few search results.

    >
    > It would take a good bit more effort than USENET is worth for someone to
    > put together a comparative benchmark of performance between a real
    > language and a hypothetical language.


    Where did I point to USENET? I gave a couple links to a masters thesis
    and an article from the peer-reviewed ACM Transactions on Programming
    Languages and Systems, and that's the tip of the iceberg. People have
    been developing techniques for making multimethod dispatch usable
    and/or competitive -- which is not the same as cost-free -- for years.

    > You provide a pseudo-comparison in which the authors compare the
    > techniques using a worst case scenario piece of code,


    They didn't do worst case code, they did common case code, namely what
    most programmers do with multimethod dispatch: write a sequence if
    instanceof tests. Sure you can do better if you work at it. The point
    is that it's better if the compiler writers did that work for you.

    > I'm all for giving something a fair shot, but I think you're
    > misrepresenting the issue by claiming that general polymorphism on
    > parameters in Java might possibly not have a performance impact.


    As far as I can tell, you're not, at least on this particular point,
    since you've repeatedly misquoted me and misinterpreted my points in
    the worst possible way.

    I'm sure this is long past the interest of any other readers. Feel
    free to grab the last word.
     
    Chris Riesbeck, Nov 3, 2003
    #18
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. sunil panda

    Lower bound & Upper bound

    sunil panda, Dec 25, 2003, in forum: Java
    Replies:
    9
    Views:
    7,253
    thushara wijeratna
    Oct 7, 2008
  2. Rhiner Dan
    Replies:
    1
    Views:
    748
    Mike Wahler
    Mar 27, 2005
  3. Mario Krsnic
    Replies:
    0
    Views:
    382
    Mario Krsnic
    Jun 23, 2006
  4. Mr. SweatyFinger
    Replies:
    2
    Views:
    1,994
    Smokey Grindel
    Dec 2, 2006
  5. Wes Gamble
    Replies:
    10
    Views:
    150
    Per Velschow
    Jan 12, 2007
Loading...

Share This Page