Re: OBJECT-ORIENTED CLX

["David C. Martin" <dcmartin@CS.WISC.EDU>]

Your message:

> This shouldn't be a problem.  CLUE represents each input event as an
> instance of the (single) event class, but minimizes cons'ing by reusing
> existing event objects from a resource cache (typically, the cache is
> just one object)....
> 
> I don't have CLUE performance numbers handy, but I'm certain allocation
> of event objects is no bottleneck.  Total user response time for
> typing/echoing a character in a text editor contact is always adequate
> for interaction (could be better, though).  This includes lookup of the
> handler method, which in CLUE can be complex and which has not even
> been optimized in the current version.

I implemented the cache stuff (and did it for all subclasses) and it only
saved me about 6ms.  I think part of my performance problem was using PCL
and also I was running on a Sun3/280 and not dedicated LISP hardware.  My
point was not that you can't make such a system work effectively, but there
are possibilities to make it work *better*.  I don't think that any OO system
will ever perform as well as the underlying support (nb: the reasoning of 
method dispatch being at best 1.5x a function dispatch) even given a totally
optimized CLOS.  What I was looking for was a clean way to let the expert get
his stuff to go AFAP (as fast as possible), sorta like the C asm statement,
only better integrated and more portable.

> What does this mean?  Moon guessed correctly!  I'd like to define an
> event subclass with something like a SATISFIES type specifier.  For
> example, a button-1-press would be a subclass of a button-press event
> such that (= 1 (event-code event)).  But, this can't be done directly,
> which is a CLOS fact, not a CLX fact.
> 
> In the case of (defmethod handle-event ((w window) (e event))), then,
> the goal would be for CLX to rely only on regular ol' CLOS method
> dispatch to automatically pick the right effective handle-event method,
> not only with a programmer-defined event class lattice (this is another
> problem entirely) but also using these SATISFIES-type event subclasses
> (this is the aforementioned CLOS problem; I'm still pondering Moon's
> suggested workaround).

Okay, now I get it.  I wanted to do the same thing and found the exact 
limitation that you encountered.  What I did was extend my event handling
to allow for the descriptors of the raw events to be mapped to particular
subclasses of events which could then cons the appropriate event object.
For example, this would allow the user to specify that a CTL-META-X meant
repaint-window-event or some other totally non-window based event (e.g.
up-line-event).  As for Moon's suggestion, I will have to peruse the CLOS
spec. for enlightenment.

dcm