Re: OBJECT-ORIENTED CLX

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

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. 
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.  I tried this approach in my OO X window
system for V10 (XCLOS) and found that I typically handled the null event 
function case (i.e. an event which caused nothing to happen) in about 75ms.

I was concerned with this performance problem, but wanted to retain the ability
to let the novice user write an event loop consisting of:

(loop (dispatch-event (get-next-event)))

In order to provide optimizations, I added a hashing mechanism on something
I called the _descriptor_ of an event (e.g. type) which could be quickly
retrieved from the raw (i.e. C language) event information.  This descriptor
could then be hashed to a particular function or method which would expect
a raw event argument and might make use of low-level functions in order to 
perform the handling.

Interestingly, the small loop did not have to change at all, but I was able
to hand-optimized and in-line the critical handlers for my window objects to
provide performance in the range of 18ms for the null event case.

I have always thought that it was best to provide several layers to any system,
with the top-level being easy to use, but perhaps slow when the novice defined
new objects, and the lower-levels integrating cleanly into the higher layers 
and providing the expert with the ability to produce highly optimized code 
which could make use of the underlying support system (e.g. CLX or XCL).

Lastly, I didn't quite understand the following:

----- from Kerry Kimbrough (10/31/88)

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.

------ end

Could you elucidate?  I haven't used CLX enough to understand the limitation.

dcm