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

Random metaclasses for CL types

re:  I think that funcallable-standard-class shouldn't be a subclass of
     built-in-class. That would break the intuitive concept of 
     specializations: the specialization refines the behavior of its 

My note didn't suggest that FUNCALLABLE-STANDARD-CLASS be a subclass of
BUILT-IN-CLASS -- I only remarked that there is no reason why it _can't_
be a subclass of STANDARD-CLASS.  In the reverse direction -- whether
STANDARD-FUNCTION-OBJECTs can have a metaclass that is a subclass of
BUILT-IN-CLASS -- well this is probably an implementational issue,
isn't it?

But on the other hand, I don't see how the "rule of refinement" applies
here.  Suppose the class B-OBJECT is a "refinement" of A-OBJECT; my
message was to elucidate that this does not imply that that the
metaclass for B-OBJECT must be a subclass of the metaclasss for 
A-OBJECT.  That is, the subclassing relations between metaclasses
are more concerned with _how_ the metaclasses describe the details of
their end-products than with _what_ the shape of each end-product is.

    misleading.  One can think that Common Lisp functions are 
    standard-function objects. I agree that the current name 
    FUNCALLABLE-STANDARD-CLASS doesn't fit well in the nomenclature, but 
    it is strange enough so it does not have the wrong connotation. 

I don't follow the reasoning here either.  Why would anyone ever think 
that a class named STANDARD-FUNCTION-OBJECT covers Common Lisp (non-
generic) functions?   Does anyone ever jump to the conclusion that Common 
Lisp data types are elements of STANDARD-OBJECT just because of the name?

-- JonL --