[3757] in java-interest
Re: Fundamental flaw in Java library distribution scheme
daemon@ATHENA.MIT.EDU (Jim Graham)
Sat Nov 25 21:12:49 1995
Date: Sat, 25 Nov 1995 15:20:07 -0800
From: flar@bendenweyr.Eng.Sun.COM (Jim Graham)
To: java-interest@java.Eng.Sun.COM, david@longview.com
Cc: wnj@sw.central.Sun.COM
I wrote:
> >You keep claiming to have an overriding case and an overloading case to
> >this problem, whereas what you are really trying to make is a case
> >about how return types would cause a method override to fail and
> >another case about how a different argument type would cause a method
> >override to fail. When you change an argument type you are not <<<<**
> >overriding but overloading and you cannot expect the new method to
> >automatically override calls to the original method. Read further for
> >more detail:
Dave wrote:
> There appears to be a nearly 100% failure to communicate going on here.
> If you look at the emphasis I have added above, you once again claim that I
> am trying to override by changing argument types.
Since that is not what I said above and you yourself quoted me, I agree
that there is a failure to communicate. Changing an argument type results
in overloading. That much we agree on.
Expecting the new method with different argument types to automatically
catch calls to a formerly inherited call is, I guess, where the
terminology gets tricky. I would call that concept an "expectation of
overriding behavior" whereas others apparently simply refer to this as
"dynamic run-time evaluation of the choice of overloaded methods".
Either way, the facts are that Java does not automatically switch to a
new overloaded call at run-time. That is the definition of the language.
There is no fundamental flaw in the distribution scheme, there is just
a definition of method dispatch behavior that you don't agree with. The
example you gave has a very simple work-around which I've detailed
several times (i.e. duplicate the method signature exactly and perform
your own dynamic run-time type checking in that overriding method).
> I never did claim that, and the academics who have followed this closely have
> had no problems whatsoever understanding my point, nor its importance.
I understand what you want and that you feel it is important, but you
don't seem to believe that the language is perfectly well defined and
useable without the behavior that you seem to feel is supposed to
be there. If that behavior was absolutely fundamentally necessary then,
yes, I would agree that there was a fundamental flaw in our distribution
scheme, but the existing definition of the language is perfectly viable
and the behavior you wish can be easily achieved using the Java language
as defined per my work-around. You have yet to address in any way
how that work-around fails to meet your needs, but I believe you have
made your point that it failed to meet your up-front expectations.
> I appreciate your attempt to address my concerns, however, I will not discuss
> this issue further with you.
I agree that we should put this to rest. The Java distribution scheme is
not currently under negotiation, so the whole discussion is moot. Either
way, I would rather leave you understanding the Java constraints and how
they *can* work than to leave you believing that there is a fundamental
flaw that will prevent Java from reaching its goals. If you persist in
expecting a specific behavior from Java and complaining about its lack
rather than seeing what is available in Java and how that can meet your
goals, then I agree that further discussion is pointless. Why don't you
ask how something can be done than to claim that it can't be done because
the mechanism you want to use doesn't work?
...jim
-
This message was sent to the java-interest mailing list
Info: send 'help' to java-interest-request@java.sun.com
