This is the mail archive of the kawa@sourceware.cygnus.com mailing list for the Kawa project. See the Kawa home page for more information.
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