From what I understand about Java, it picks the method to execute based on
the run-time class of the receiving object and the compile-time classes of
the arguments (i.e. - dynamic resolution for the receiver, static
resolution for the arguments).
In Java code that I and others have written, there are situations where,
in order to invoke the "appropriate" method, one must cast an argument to
a particular class, since the static binding (without casting) would have
selected a method "higher" in the partial ordering of methods based on the
class hierarchy. Safely casting in this manner requires either [1]
assurance that the casting will in practice work in all cases or [2]
special logic that maneuvers control to the appropriate method-call based
on argument classes.
It may be that the casting mentioned above is symptomatic of poor
class/method design in some cases. But it's not clear to me that in the
course of developing reasonable code one can always avoid such casting.
And in some cases, this casting adds conceptual baggage that gets in the
way of solving the problem at hand, just as allocating and deallocating
memory introduces complexities to a body of code.
Having used dynamic languages much more than static languages, my
preference would have been for Java to perform method resolution based on
the run-time classes of the receiving object AND all argument objects. The
receiver object would no longer have a special status. Then the casting
issue would go away [perhaps other issues would be born out of this
disappearance?] and I could view method resolution as a kind of run-time
pattern matching of receiver and argument classes [similar to how one can
write code in Dylan and the Common Lisp Object System (CLOS)].
I know that differences in language design often have little or no bearing
on the total cost or benefit of the development, use, and maintenance of a
body of software. And I will grant that I have always preferred to rely
on the agency of high-level programming languages to shield my efforts in
solving real-world problems from the vagaries of The Machine.
All of which is a long way to give some background as to why I would like
to ask the following questions to anyone interested in answering.
1. [Java designers -- are you there?] Was the (receiver = dynamic
resolution; arguments = static resolution) decision a conscious one? If
so, what were the major reasons for the decision? Performance? Ease of
implementation? Operational considerations regarding how Java manages the
loading and binding of classes and methods? Similarity to the semantics of
C++?
2. I know of several efforts to use the Java Virtual Machine to support
other languages including ADA and Scheme. Would it be possible to
implement a dialect of Java using the JVM that supports run-time method
resolution based on receiver AND argument objects? If so, how difficult
would such an implementation be? Though at first glance it does not seem
like there need be any syntax changes, would the changed semantics require
any changes to Java's syntax? [Dylan implementors: can the JVM handle
singletons?]
3. [CLOS/Dylan audience] Which aspects of CLOS/Dylan would you rather see
Java support than a multi-method style of method dispatch? Closures?
Continuations? Multiple-inheritance? [My opinion today: neck and neck with
closures]
Apologies for the length of the message / Gary
--
Gary Beaver
······@teleport.com