Name: mc57594			Date: 12/16/99

java version "1.1.3"  (<<<-- 1.1.3, or 1.3? )

Has anyone considered the possibility of adding object-oriented callbacks to
Java?  The idea would be to define an object which can receive a reference to an
object and an associated member function for later execution.  Such an object
could be declared as follows:
<pre>
    <b>callback</b> type <i>callbackName</i>(type1,type2,...);

</pre>
The <i>callbackName</i> is initially empty.  If you call it as a function,
nothing happens and in the case of a non-void return type a <b>null</b> is
returned.  However, you could at some point make the following assignment:
<pre>
    callbackName = myObject.myFunction;

</pre>
This would be checked at compile time to make sure that <i>myFunction</i> is a
member of the class of <i>myObject</i> and that its argument and return types
match those of <i>callbackName</i>.  If <i>myFunction</i> is overloaded, the
appropriate version is selected.  At any rate, when <i>callbackName</i> is
called with the appropriate arguments, it is as though
<i>myObject.myFunction</i> is called with those arguments.  Later, if you assign
<b>null</b> to <i>callbackName</i>, subsequent calls to <i>callbackName</i>
would do nothing (or return <b>null</b>).
<p>
You could also compare <i>callbackName</i> to <b>null</b> and change the
behavior of the containing object depending on if anything is assigned to
<i>callbackName</i> or not (kind of like plugging in
an earphone to disable the loudspeakers on a radio.
<p>
Such a feature would be extremely straight-forward to deal with. Rather than
declaring a function to be overridden in a derived class (or anonymous class),
you would simply create your component objects and then, in effect, wire them
together.  You could even imagine graphical representations of these wires which
are objects with position and other visual characteristics.  These would simply
be objects with input functions and output callbacks which are in turn wired to
other visual objects.
<p>
Although this kind of thing can be implemented with Reflection, it would have
none of the complexity and overhead of Reflection.  Chances are it would be
widely used if it were available.
<p>
It also has none of the limitations of interfaces.  An Interface is sort of like
a set of standard bus pins on a card.  Plug it in and it does whatever it does.
That is all well and good but what you might really want is a chip you could
mount on a board with however many connections hooked together in whatever way
you need it.
<p>
Internally a callback would probably be stored in much the same way as an
interface reference is.  When you assign an object whose class contains an
interface to an interface object what is really stored is an object reference
and an offset into the method table for that object.  That is exactly what is
needed here.
<p>
Ben Jones
(Review ID: 98897) 
======================================================================
Mark,

The page on which I submitted a bug fix was messed up first by not
taking my supplied HTML
tags into account and by not taking preformatting into account in my
followup post.  Here is the
corrected page.
----------------
There's nothing I can do about this.
Internally, the bug is as you sent us.
When the bugs are pulled out of the database
and put on the web site (nightly), they
do some conversions.

Looks like they convert all '>' to '&gt'.
Good idea, though.

Mark Chamness