Clarification of JavaLive delegates criticism?

[Jeffrey T. Smith]

Back when the new J2SE1.5 features were announced, there was a
JavaLive community chat
(http://java.sun.com/developer/commun...03/jl0729.html)
in which Neal Gafter explains the Sun stance on lack of support for
delegates:

.... There are serious semantic problems with trying to add delegates
to a language in a consistent way. The main problem is that once you
call the delegate, the original class instance is no longer part of
the call chain, so overriding in the original class no longer takes
precedence over the delegate. ...

Could someone please explain this to me a little more fully? It
sounds like he's saying that delegates cannot follow a subclass call
chain if they are created from an object stored in a superclass
reference, but I can't tell if he means overriding delegates
themselves. I would like to know:
1) What exactly does he mean in less ambiguous terms? (Or maybe just
simpler terms; it's been a while since my college programming
languages course.)
2) What an example of delegates 'failing' like this would look like.
3) What is so significant about this problem.

I am already familiar with the 'Truth about Delegates' dialogue
between Sun and MS and the lack of true type safety of C# delegates,
but not understanding this criticism bothers me. Any help would be
greatly appreciated.

Thanks,
Jeff

[JTK]

Jeffrey T. Smith wrote:

Back when the new J2SE1.5 features were announced, there was a
JavaLive community chat
(http://java.sun.com/developer/commun...03/jl0729.html)
in which Neal Gafter explains the Sun stance on lack of support for
delegates:

... There are serious semantic problems with trying to add delegates
to a language in a consistent way. The main problem is that once you
call the delegate, the original class instance is no longer part of
the call chain, so overriding in the original class no longer takes
precedence over the delegate. ...

Could someone please explain this to me a little more fully?

Sure: Sun has taken a stance that "Delegates are Bad" because C# has
them and Java doesn't, and now has to come up with a psuedo-technical
reason for not implementing them to feed to the Java "Community Process".

[Christophe Vanfleteren]

JTK wrote:

Sure: Sun has taken a stance that "Delegates are Bad" because C# has
them and Java doesn't, and now has to come up with a psuedo-technical
reason for not implementing them to feed to the Java "Community Process".

You've got your timetable screwed up. Sun has always opposed delegates in
Java. This already started in the days that Microsoft implemented them in
their version of the 1.1 JVM (J++) and so has nothing to do with C#.

Look at http://java.sun.com/docs/white/delegates.html for an explanation of
Sun's viewpoint.

--
Kind regards,
Christophe Vanfleteren

[Jeffrey T. Smith]

> Look at http://java.sun.com/docs/white/delegates.html for an explanation of

Sun's viewpoint.

Thanks, I've already read this and MS's response at
http://msdn.microsoft.com/vjsharp/pr...h/default.aspx
.. However, neither address the issue brought up at the far more
recent JavaLive talk. It seems to me like Sun is claiming that not
only is the C# implementation flakey (with which I definitely agree),
but that having delegates in a purely OO language (as a true partial
closure covering a single object) in an OO manner is something that no
one has figured out how to do in a consistent manner. C# delegates
act more like typedefs thans objects, and a 'true' delegate would
probably behave more like a single-method interface, supporting
inheritance, true type safety, etc. They are conceptually ideal when
using event handling (i.e., associating sets of methods with
individual objects), while Java is both visually and conceptually
clunky, but are really still broken in a lot of ways. I realize that
C#'s delegates aren't perfect, but what is Sun's excuse that first
class functions -can't- be done elegantly in this environment?

[Roedy Green]

On 23 Jun 2004 08:38:29 -0700, Ge*******@netscape.net (Jeffrey T.
Smith) wrote or quoted :

. However, neither address the issue brought up at the far more
recent JavaLive talk. It seems to me like Sun is claiming that not
only is the C# implementation flakey (with which I definitely agree),
but that having delegates in a purely OO language (as a true partial
closure covering a single object) in an OO manner is something that no
one has figured out how to do in a consistent manner.

The complaint is not with the inner class/delegate implementation that
Java uses, just that it requires so much typing for simple cases.
This obscures what is happening. If you simply invented some syntatic
sugar that amounted to a macro to generate the bubblegum, you would
satisfy most people.

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

[JTK]

Jeffrey T. Smith wrote:

Look at http://java.sun.com/docs/white/delegates.html for an explanation of
Sun's viewpoint.

Thanks, I've already read this and MS's response at
http://msdn.microsoft.com/vjsharp/pr...h/default.aspx
. However, neither address the issue brought up at the far more
recent JavaLive talk. It seems to me like Sun is claiming that not
only is the C# implementation flakey (with which I definitely agree),
but that having delegates in a purely OO language (as a true partial
closure covering a single object) in an OO manner is something that no
one has figured out how to do in a consistent manner. C# delegates
act more like typedefs thans objects, and a 'true' delegate would
probably behave more like a single-method interface, supporting
inheritance, true type safety, etc. They are conceptually ideal when
using event handling (i.e., associating sets of methods with
individual objects), while Java is both visually and conceptually
clunky, but are really still broken in a lot of ways. I realize that
C#'s delegates aren't perfect, but what is Sun's excuse that first
class functions -can't- be done elegantly in this environment?

Again, Sun's excuse is "Microsoft did it before we did".

[Peter Ammon]

JTK wrote:

Jeffrey T. Smith wrote:

Look at http://java.sun.com/docs/white/delegates.html for an
explanation of Sun's viewpoint.

Thanks, I've already read this and MS's response at
http://msdn.microsoft.com/vjsharp/pr...h/default.aspx

. However, neither address the issue brought up at the far more
recent JavaLive talk. It seems to me like Sun is claiming that not
only is the C# implementation flakey (with which I definitely agree),
but that having delegates in a purely OO language (as a true partial
closure covering a single object) in an OO manner is something that no
one has figured out how to do in a consistent manner. C# delegates
act more like typedefs thans objects, and a 'true' delegate would
probably behave more like a single-method interface, supporting
inheritance, true type safety, etc. They are conceptually ideal when
using event handling (i.e., associating sets of methods with
individual objects), while Java is both visually and conceptually
clunky, but are really still broken in a lot of ways. I realize that
C#'s delegates aren't perfect, but what is Sun's excuse that first
class functions -can't- be done elegantly in this environment?

Again, Sun's excuse is "Microsoft did it before we did".

I don't see where Sun says that. Rather, they point out that delegates
complicate the language, and claim it's not worth the cost. I'm
sympathetic to that position. Lots of things about delegates are very
confusing to me, and the more I read the more confused I become. For
example, "The invocation list of a delegate is an ordered set of
delegates in which each element of the list invokes exactly one of the
methods invoked by the delegate." Huh? And there's "delegate
arithmetic," and an inability to derive from them...

Microsoft's response to the weird semantics of delegates seems to be
"Java has weirdness too, like arrays and strings, and that doesn't make
Java more complicated/poorer!" Well, I say it does, and the same logic
applies to delegates as well.