CLIM mail archive
[Prev][Next][Index][Thread]

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 <miller@cam.nist.gov>

	...

	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
question.

I have the following class hierarchy:

OBJECT
  OBJECT-WITH-PARTS
    OBJECT-WITH-COMPONENTS
      PACKAGE
      MODULE
    MODULE-COLLECTION
      CLASS
      PACKAGE        
[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
something like

(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 ...)
  <from hashtable>)
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!

Any thoughts?

  bruce
  miller@cam.nist.gov
Follow-Ups: References:
Main Index | Thread Index