Re: Needed: Info on LISP X based toolkits

[Mike McMahon <MMcM@SCRC-STONY-BROOK.ARPA>]

It seems that I may not have successfully conveyed my position
originally.  So, I am somewhat unsure what it is that you then agreed
with and have now changed you mind on.  Of course, I will not rule out
the possibility that we disagree.

The situation with :EXPOSE is meant merely as an example of an area in
which a protocol must be careful about its specification.  Certainly, it
is not an indication of the impossibility of the task of an object
oriented window system.  Nor is the way in which the situation was (or
was not) rectified in the LISP machine window systems directly relevant.
The suggestion with exactly that these experiences be used as a basis
for improvement.

My point concerning cursor attachment mixins was this: I do not see a
valid protocol definition under which this makes sense.  Either the line
drawing operation is defined to affect the cursor, or it is not.  I
contrast this with an operation to draw some text and move the cursor.
Here, there is a perfectly valid class which moves the cursor to the
left rather than to the right, the notion of text movement being general
in the protocol description.  In my opinion, nothing has been gained by
redefining the draw-line operation, except saving the bother of coming
up with a different name for the new operation.

My motivation for not using CLOS in CLX is more fundamental than the
specifics of the cases which you cited.  Once again, it is a matter of
having a clear protocol.  The semantics of the X protocol, and hence of
CLX, are exactly determined by the server.  There is no flexibility
there.  Hence, a dependent specialization that changed those semantics
would destroy the isomorphism.  For this reason, I recommended
structures and normal functions.  Of course, this does not mean that one
could not use instances for the objects and generic functions for the
operations.  Nor would doing so immediately and necessarily result in
disaster.  However, in a properly constructed higher level toolkit, the
instances would only be extended and the operations encapsulated.  In
other words, the result would be functionally identical to having the
lower level structures as instance variables.

I do not see it as a problem that your higher level toolkit had to
define a lot of generic functions that do just a single server
operation.  In my opinion, to merge the two would have been a false
parsimony.  It hides the additional semantics which you (presumably)
attached to the higher level operations.  If in fact, your operations
are identical to those of the server because they make sense even at the
next higher level of abstraction, then perhaps you should indeed lobby
the authors of CLX to migrate to CLOS.  It is an implementation tradeoff.

>From hard experience, I know that object-oriented programming, or
information hiding in general, should not mean that the left hand does
not know what the right is doing.