[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

find my slot

    Date: Thu, 29 Nov 1990 17:58 EST
    From:	Jon L White <jonl@lucid.com>

    re:     Date: Tue, 27 Nov 1990 12:06 EST
	    From:	davis@ilog.ilog.fr

	    Of the 5 major CLOS metaobject types (classes, generic functions, 
	    methods, method combinations, and slot definitions), three have 
	    and one doesn't need one (generic functions).  What happened to

	It isn't necessary, because CLASS-DIRECT-SLOTS and CLASS-SLOTS are 
	specified to return lists, therefore the existing FIND function can be 
	used (with  :KEY #'SLOT-DEFINITION-NAME).

    If Harley's question is only about introspective capabilities, then
    we don't need FIND-METHOD either -- because of the documentation for

It's true that FIND-METHOD doesn't do anything you can't do yourself given
those other facilities.  It also doesn't do anything that's useful, as far
as I can see, if all you have is the standard part of CLOS (chapter 2).
I imagine FIND-METHOD exists because the translation into FIND is quite
complicated.  I notice that FIND-METHOD is generic, so maybe it exists
so users can define other methods for it.  However, I can't imagine what
one could accomplish, other than perhaps a minor speedup, by writing
specialized methods for FIND-METHOD.

    However, FIND-CLASS and FIND-METHOD are "Chapter 2" facilities.  Would
    you now propose to remove FIND-METHOD?  or would the uniformity of
    interface resulting from the addition of FIND-SLOT-DEFINITION be 
    better than trying to retrench into a minimal kernal language?

I'm not proposing anything.  I will comment that attempting such
uniformity of interface in CLOS is pretty much a lost cause; CLOS
just shows too well that it is the work of many hands.

The absence of FIND-SLOT-DEFINITION is one of the few things about the
most recent draft of the metaobject protocol I have (July 30, 1990)
that doesn't bother me one little bit.