[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Random metaclasses for CL types
However I don't see any particular consequence of requiring
FUNCALLABLE-STANDARD-CLASS to be a subclass of STANDARD-CLASS rather
than of BUILT-IN-CLASS. It's certainly possible for one subclass of
STANDARD-CLASS to paint a totally different picture of its instances
than some other random subclass of STANDARD-CLASS does.
I coudn't parse that, so excuse me if what I say is totally obvious to you. 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 superclass.
Rather, I would like
to see a clear picture as follows, where the dots show metaclass links,
and the slashes show subclass links:
FUNCTION . . . . . . . . . . . . . . . . BUILT-IN-CLASS
/ \
/ \
/ \
?? STANDARD-FUNCTION-OBJECT . . . . . . . STANDARD-FUNCTION-CLASS
/ \
/ \
/ \ GENERIC-FUNCTION
/ \ /
/ \ /
{PCL's "constructors"} STANDARD-GENERIC-FUNCTION
Are you suggesting to add STANDARD-FUNCTION-OBJECT in the standard? I don't
have anything against it. It's just I am not clear on what you want.
The advantage of using the name STANDARD-FUNCTION-CLASS rather than
FUNCALLABLE-STANDARD-CLASS is that it continues the parallels already
established between the nomenclatures of certain other meta objects:
STANDARD-OBJECT -- STANDARD-CLASS
STRUCTURE-OBJECT -- STRUCTURE-CLASS
{BUILT-IN-OBJECT} -- BUILT-IN-CLASS
{STANDARD-FUNCTION-OBJECT} -- STANDARD-FUNCTION-CLASS
The names STANDARD-FUNCTION-OBJECT and STANDARD-FUNCTION-CLASS are 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.
Patrick.