Re: OBJECT-ORIENTED CLX

[Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>]

   > I tend to agree with JAK that it would be better to leave CLX alone and work
   > on a higher-level abstraction (e.g. CommonWindows) at which to provide OO.

This point is controversial, but fortunately it is irrelevant to this discussion
of Warren's proposal for integrating CLX with CLOS. 

   > As for the question of event dispatching, there is a *lot* of overhead with
   > the use of:
   > 
   > (defmethod handle-event ((w window) (e event))
   > 
   > Especially in the cons'ing of the event object from the server data and the
   > lookup of the appropriate method.

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).
Currently, the event class is a "union" of slots for all X events; those slots
which do not "belong" to the event-key have NIL values. But it wouldn't be hard
to extend this approach to 1 cache per event subclass.

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.

With (defmethod handle-event ((w window) (e event))), method lookup should be
fast, else you've got a poor implementation of CLOS, else CLOS has not acheived
its goal of efficient implementability.

   > This alternative would be much improved if there actually was a way for CLX to
   > dispatch on programmer-defined subclasses *inside* process-event.  It's not
   > clear how to implement this.  Another thing is that I've noticed it's
   > frequently useful to define a new event subclass procedurally, either via a
   > relation predicate over its slots (e.g.  :button-1-press, :shift-button-press,
   > etc.) or by a function of the event stream (e.g.  :double-click).  But, CLOS
   > doesn't handle these kind of (sub)classes.

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).