In cltl2, p. 781 it says that:
"Each class that corresponds to a predefined Common Lisp type can be
implemented in one of three ways, at the discretion of each
implementation."
Those three ways being standard-class, structure-class, or built-in-class
I would like to see future LISP implementations implement sequences (lists,
simple-vectors, strings) as standard-classes rather than non-extensible
built-in-classes. If anyone knows of any that do please let me know how
to get it. Another thought for future implementations of LISP/CLOS (or
should that be CLOS/LISP) is to CLOSify all of LISP and make everything
inherit from standard-class like numbers, strings, arrays etc? (Except for
structures which would be kindof redundant; they could just be an optional
collection of objects that are used only for compatibilty for older LISP
applications)
Any comments?
In article <·····················@ciit85.ciit.nrc.ca> ········@ciit85.ciit.nrc.ca writes:
I would like to see future LISP implementations implement sequences (lists,
simple-vectors, strings) as standard-classes rather than non-extensible
built-in-classes. If anyone knows of any that do please let me know how
to get it. Another thought for future implementations of LISP/CLOS (or
should that be CLOS/LISP) is to CLOSify all of LISP and make everything
inherit from standard-class like numbers, strings, arrays etc? (Except for
structures which would be kindof redundant; they could just be an optional
collection of objects that are used only for compatibilty for older LISP
applications)
In most CL implementations, STRUCTURE-CLASSes offer somewhat more
efficient slot access than STANDARD-CLASSes. Since even
STRUCTURE-CLASSes offer user-extensible (single) inheritance and
method specialization (i.e., at least as much object-orientedness as
Smalltalk classes) it might make sense to suggest simply that CL
implementors--and, eventually, the CL standard--progressively reduce
their set of BUILT-IN-CLASSes. Note, though, that even
BUILT-IN-CLASSes offer method specialization on their own
(language-defined) inheritance hierarchy.
I would also point out that inheritance is of limited value without
method specialization, and non-generic functions do not permit the
latter. Thus, any proposal for increasing the object-orientedness of
Common Lisp should include a progressive changeover from FUNCTIONs to
GENERIC-FUNCTIONs. X3J13 has already done this for the DOCUMENTATION
function.
Lawrence G. Mayka
AT&T Bell Laboratories
···@iexist.att.com
Standard disclaimer.