[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LISP X based toolkits
Received: from ti.com by SAIL.Stanford.EDU with TCP; 6 Oct 88 19:08:51 PDT
Received: by ti.com id AA22384; Thu, 6 Oct 88 21:06:07 CDT
Received: from dsg by tilde id AA00678; Thu, 6 Oct 88 19:37:40 CDT
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Thu, 6 Oct 88 19:37:13 CDT
Date: Thu, 6 Oct 88 19:38:16 CDT
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
To: Warren Harris <harris%hplwhh@HPLABS.HP.COM>
Subject: Re: LISP X based toolkits
In-Reply-To: Msg of Thu, 06 Oct 88 00:15:45 PDT from Warren Harris <harris%hplwhh@HPLABS.HP.COM>
> Adopting a full level (3)
> would pretty much leave (2) obsolete, and since level (3) would then have
> to be at least as powerful as (2), we would consequently be programming to
> just a different version of (2). This argues for the (2.5) (CLUE)
Bingo. Exactly our rationale.
> I'm not saying the concept of a Common Lisp User
> Environment should be eliminated, but we should rethink what we mean by
> supporting various levels of a window system. I think this means providing
> a set of classes which understand both the X server and the necessities of
> CL (such as streams), and a means of extending these classes when
CLUE's interactive-stream contact is a stab at this. Here, the idea is that there
exists a *special* kind of window which can act just like a CL-standard char
stream, as an arg to read, write, etc. But not every window is a stream. From
time to time, I seem to hear the notion that all window are streams, that
"stream" is the all-encompassing metaphor. But this has always baffled me.
> For one, the degree
> to which CLUE is object-oriented is completely ad hoc...
> (Was this in the name of efficiency or what?)
No. Merely a practical matter of minimizing the "bastardization" of off-the-shelf
CLX. A matter which I'm certainly willing to reconsider.
> Finally, the notion of callbacks seems more like a throwback to C to me.
> Perhaps this is what Lanning is alluding to in his comments about the
> XToolKit. Why aren't these callbacks generic functions which can be
> overridden or inherited by subclasses of the class for which they're
> defined? That would seem cleaner and more straight forward to me.
The idea is that a callback is instance-specific behavior, not class behavior.
That is, every instance of a given class of UI objects has a unique set of
application semantics, which is represented by its callbacks. Further, the
application semantics of a contact instance is defined by the application
programmer and is *unknown* to the contact programmer who defines the contact
You can also imagine other ways of packaging callbacks. I suppose that in CLUE
we opted for maximum flexibility because we weren't willing to claim that we
knew the "right" way to structure the callback interface. For example,
sometimes a callback communicates with the application, and sometimes it
communicates with some other object in a structured UI. Sometimes, the
application wants to know which contact is reporting; sometimes it doesn't care.
Sometimes the contact knows all the data to return; sometimes the application
wants to attach extra data. Sometimes the application wants to define semantics
for a contact action; sometimes the application finds it convenient to ignore
the action. Sometimes the application consists of objects and callbacks will
invoke their methods; but sometimes not. Sometimes you're building up both the
UI and application together; sometimes you're slapping a new UI on an existing
set of application functions. Etc.
One rightful objection to the way CLUE works is that invoking callbacks involves
a look-up that is a lot like method dispatch, so why does it have to be
different? Another approach has recently been pointed out to me. Instead of
looking up a function associated with a 'callback-name, the contact calls the
generic function 'callback-name. The application programmer defines a
instance-specific method for 'callback-name by using an (eql <instance>)
specializer. The method would be created dynamically by using something like
(make-instance 'standard-method ... :function #'application-function-closure
...) and add-method. Why didn't we do this? It didn't occur to us until now! Hey,
10-4 on that CLOS learning curve. Anyway, I'm looking into this, and I'd
appreciate any advice on its pro's and con's.
> I'm sorry if the flames are hot.
No problem. I like the fire, not the cold.