[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: OBJECT-ORIENTED CLX
> Date: Tue, 01 Nov 88 23:51:58 PST
> From: Warren Harris <harris%hplwhh@HPLABS.HP.COM>
> I want to reiterate again why I think approach 1 to event dispatching is
OK, you convinced me.
> > Very little of the existing
> > CLX programmer interface ought to change.
> On the surface this may seem true, but there is a fundamental difference.
> Requiring CLX to be object-oriented would change the way applications would
> use it.
Agreed -- (not (eq clx oo-clx)). But (equalp clx oo-clx)? My point is spelled
out perhaps more clearly in my reply to David: we're talking about a system
which, by definition, is the same as CLX (not strictly but in a strong sense).
Similarly, CLOS is designed to mesh smoothly with non-OO Lisp functions.
Therefore, there is little reason for OOCLX to diverge from CLX -- neither
semantically nor syntactically. Where divergence can be soundly justified,
fine. But the rule of thumb should be "same until proven different".
On a practical note, CLX is already carefully designed to match up well with the
interfaces and terminology of the X protocol. Tinker with this gratuitously
(e.g. x -> outside-left) and you'll be overwhelmed by the moans, squawks, and
bleeps of the multitude of hackers already laboring away in the sulphurous lower
circles. No, don't look at it that way; look at it this way: it'll make the
transition from CLX to OOCLX cheaper.
> I was thinking that you could just save the init-plist on the object when
> you did a MAKE-INSTANCE call. This would require just 1 slot. OPEN-OBJECT
> would then take the init-plist apart. CLOSE-OBJECT could build a new
> "init-plist" for the next time the object is opened, by querying the server
> for all the object's attributes before it actually issued the destroy
> request. The alternative is to actually allocate all the :X-SERVER slots
> with :INSTANCE allocation, and use these slots as caches when necessary.
OK, I think the init-plist is a good idea.