Re: [patch] java.beans.EventHandler

[Jerry Quinn <jlquinn at optonline dot net>]

Bryce McKinlay writes:
 > Jerry Quinn wrote:
 > 
 > >Bryce McKinlay writes:
 > > > Hmm. It seems to me that you can infer propertyType by looking up the 
 > > > method for eventPropertyName and checking its return type? The return 
 > > > type for the event property must be compatible with the argument for the 
 > > > action, after all.
 > >
 > >Yes, but you don't yet know the class to look up eventPropertyName in when
 > >constructing the EventHandler.
 > >
 > The first argument to each listener method is the event. Is this not the 
 > class to look up eventPropertyName in?

The create method knows the listener interface to look the methods up in, but
the EventHandler constructor doesn't.  So at a minimum, whatever we do has to
allow for the case of an explicitly constructed EventHandler that doesn't yet
know the type that listenerMethodName belongs to.

Perhaps we can cache the listener method after the first invoke and use it if
the object type is the same as the previous call.  Then we'll at least get
some of the savings.

 > >  Especially when directly calling the
 > >constructor.  Even when using the create methods, let's say you create without
 > >providing listenerMethodName.  This means that all listener methods are
 > >handled by using the first argument as the event.  Each one could potentially
 > >be passed a different object type.  Which do you use to acquire the Method
 > >object?
 > >  
 > >
 > If the listener has multiple listener methods, we can look up each one 
 > individually, although I think typically in a listener interface each 
 > method will have the same argument type, so for efficiency its probably 
 > best to remember past lookups and not repeat them again for multiple 
 > methods.
 > 
 > > > Even though the chain can be heirarchical, the objects in the chain at 
 > > > runtime must still be type compatible with the properties that were 
 > > > passed into the create() method, right?
 > >
 > >Except that the properties are passed as Strings and not Classes or Methods.
 > >  
 > >
 > I don't think this is a problem. Suppose eventPropertyName is "a.b.c". 
 > First we look up "a", take the class of that, lookup "b" in that class, 
 > etc... ?

OK, this is probably a red herring.  Although, isn't it possible that
inheritence can change this at runtime?  Imagine we have a property a.b.  The
listener gets an event class A, so we would do A.getA().getB().  Now consider
the following snippet.  An event of class A is fed to the listener, and hence
to invoke.  We perform getA() on the event.  But we can't know whether to call
getB() or isB() except when invoke is called.  Gross, but allowed, no?  I
admit I'm probably not be aware of all the issues with property naming,
though.

class A
{
  A() { t=false; }
  void setT(boolean b) { t = b; }
  B getA() { if (t) return new D() else return new E(); }
}

interface B
{
  Object getB();
}

interface C
{
  boolean isB();
}

class D implements B {}

class E implements B implements C {}


Am I overthinking things here?

Cheers,
Jerry