CLIM mail archive
Reverse Inheritance of Accept Methods (was: for Gestures for commands more than 1 arg?)
Date: Fri, 17 Sep 1993 14:03 EDT
From: Scott McKay <SWM@stony-brook.scrc.symbolics.com>
Date: Fri, 17 Sep 1993 13:37 EDT
From: Bruce R. Miller <email@example.com>
Sigh, that's what I was afraid of. I was thrown off by the fact that a
single arg command apparently doesn't invoke the command-parser at all.
This is one of those cases where it's trivial to know if you've got a
THING, but harder to find the thing associated with an arbitrary name.
All the _real_ THINGS live elsewhere on the net; I fetch them
incrementally as needed. If I once open the door to allow someone to
type in the name of a THING, I'm kind of obliged to recognize _any_ THING...
I'm not surprised that this is going to be a pain. Sorry about that.
Dont feel bad. Actually it prompts an interesting philosophical
I have the following class hierarchy:
[and a few others]
The objects of real interest are: CLASS, PACKAGE, MODULE
(first 2 are shadowed in my package, of course)
One nice thing is that I can define a present method on OBJECT that
essentially prints "<type> <name>" (all objects have a name),
eg "Class A" or "Package IMSL".
This gives reasonable feedback to the user, since the only instanciated
things are class, package or module.
Various commands in the system can be defined on _any_ of the above
types, that is not only CLASS or MODULE, but OBJECT-WITH-COMPONENTS as
well, w/o any defining any more specific present methods .
CLOS & CLIM are treating me well here. :>
I can arrange to get all names of CLASS's & PACKAGE's into hashtables,
so I can write accept methods fairly easy. [MODULE's a problem for
entirely different reasons -- non-uniqueness of the name]
The quesiton is: How do I write an accept method for (eg)
OBJECT-WITH-COMPONENTS without throwing modularity out the window?
Ie, OBJECT-WITH-COMPONENTS ultimately amounts to (OR PACKAGE MODULE)
--- but I'm not supposed to know that!
My print method was inspired by the parser for Genera Namespace objects.
I could do the same here: read a token (one of package, module)
and then invoke some generic on that token that reads a class-name,
package-name or whatever. But I've _still_ got to get a list of which
leaf classes are appropriate. I suppose I could get a list of
subclasses of a class?
Alternatively, I suppose I could write an accept method that did
(defmethod do-accept (class stream ...)
(loop for sub in (clos:class-direct-subclasses clos-class)
thereis (do-accept sub stream ...)))
(defmethod do-accept ('class stream ...)
Hmm. Well it _is_ modular!
Of course, for this application, the number of classes is small enough
that it really wouldn't be difficult to write any or all parsers
explicitly. Still, it just dont seem right!
Main Index |