Re: proposal for Kawa event call-back

["Marc P. Kwiatkowski" <marc@mpath.com>]

Per Bothner writes:
 > Some helpful comments.  Thanks.
 > 
 > > This syntax seems too special case.  I guess I'd like to
 > > see something close to a "primitive-interface-constructor".
 > 
 > While I don't think it is as special case as you sedm to think,
 > I do think having a more general syntax would make sense.
 > Something like:
 > 
 >    (object (SUPERCLASS-AND-INTERFACES ...)
 >       METHOD-DEF ...))
 > 
 > where a METHOD-DEF might be something like:
 > 
 > 	(METHOD-NAME (ARGNAME | (ARGNAME ARGTYPE) ...) [RETURNTYPE] BODY ...)
 > 
 > The "object" form would be equivalent to Java's "new" of an
 > anonymous inner class.  (There would be a default "magic" constructor,
 > which makes sure that any "captured" outer variables are accessible.)

This is exactly what I'd like!  

 > 
 > I think the "listener" syntax I proposed would be a convenient
 > short-hand for the more general "object" syntax.
 > 
 > > Suppose I need an event handler for events that have nothing in 
 > > common with java.awt.event.MouseEvent (this is exactly my case now).  
 > 
 > That is handled by my syntax.  There is nothing special about MouseEvent.
 > As a *convenience*, the compiler knows about MouseEvent, so it you
 > specify a mousePressed buttom *and* you don't specify explicit
 > EVENT-TYPE and interfaces, it will fill those in for you.
 > But if you have Listener and Event types that the compiler does not
 > know about, you can specify them explicitly.

I guess it just bugs me that the compiler would know anything about 
AWT.  It seems like creeping featurism.  I'd prefer to see
a general "object" procedure as you describe above, and then leave it
to some library extension to provide a convenient set of AWT event
listeners using "object".

 > 
 > > I'd have to list those as "extra", but they aren't extra.
 > 
 > By "extra" interfaces I only mean interfaces that the compiler
 > can't infer automatically.
 > 
 > > How about this:
 > >        (primitive-interface-implementor
 > >         interface (method-assoc-list))
 > >         Return a new anonymous procedure, which when called will
 > >         create a new object
 > 
 > While this is Scheme-ish, I really hate all these anonymous procedures.
 > They add an extra useless layer of parenhesis, and add an extra layer
 > of abstraction which make it just that harder for most people to
 > unravel what is going on.
 > 
 > If in most cases, you're just going to call the anonymous procedure
 > in place, why require the parens?  I believe that is the case here,
 > which is why I prefer the specify that the syntax creates an
 > instance, rather than an anonymous procedure.  (If you need an
 > anonymous procedure, it is easy enough to add an extra lambda.)

I agree.  I dislike that about primitive-virtual-method et al.  
"object" would solve that nicely.  

 > More substantively, I'm a little confused by what you mean by
 > "for each car of each entry in method list will invode the cdr".
 > *When* is it invoked?  For example, what is the purpose of the classEvent
 > method?  Who invokes it?

I mean that given the pair ((<com.yoyodyne.Foo> "method" <int> (<int>)) . p)
generate a method definition such that a call to O.method(x),
where O a com.yoyodyne.Foo object returned by primitive-interface-implementor,
will invoke (p x) and attempt to coerce the result of (p x) into an int.

-- 
marc@mpath.com