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

Re: (long) CLOS Declaration Proposal Text

Some additional comments on the declaration discussion,
and Moon's reply. Dick Gabrial, are you still there?

>    5) If method combination is prohibited for a certain method,
>    any overhead which is needed to support method combination
>    in the general case could be avoided.
>I agree that this is a non-issue.

OK, then, unless anyone else objects, we can drop any consideration
of declarations for method combination.

>    (CLASS FOO X)
>I think (EXACT-CLASS FOO X) has a lot less potential for confusion.

This syntax is fine with me.

>    a user may want to restrict a particular name to be a generic function
>I don't see why.  I suggest leaving this out unless there is a good
>reason for it (which should be articulated).

I would like to see this resolved in the context of the GFLET,
GFLABELS, and GLAMBDA proposals discussed earlier. In particular,
I would like the ability to say:

	(MAPCAR <some local generic function> LIST-OF-OBJECTS)

and not have to do a global definition of the methods. A GENERIC-FUNCTION
declaration might allow us to get away without introducing GFLET
and GFLABELS. For example, the following could be legal:



or some similar syntax. Notice that this will not resolve the problem
of GLAMBDA, however.

>When a user creates a subclass of a "staticized" class, rather than
>changing the semantics in some unclear way, I suggest signalling an
>error if there is a conflict between the semantics frozen into the
>superclass and the semantics that would exist if the superclass had not
>been "staticized".  The design principle here is that adding a
>"staticize" declaration to a working program shouldn't change what it
>does, only how fast it does it.

I agree here.

>The name MAKE-STATIC isn't the best.  To me, it connotes a function that
>returns an object that I can hand to the WRITE-SOUND function and get an
>ugly noise from the speaker in my console.  FREEZE-CLASS would be better.

I like the idea of using FREEZE-<something> for optimization and other
postdevelopment processing. I would suggest the following additions to
the metaobject protocol for this purpose:


Takes a class object as an argument and causes the definition of the
class to be frozen. Any attempt to redefine the class will cause an
error to be signalled. In order for a class's definition to be frozen,
all superclass definitions must be frozen as well. An error will be
signalled if this is not the case.


Causes slots to be located at fixed offsets if the class is used as
a superclass during inheritence. Signals an error if all superclasses
do not have frozen slot layout as well.


The class precedence list for the class argument is calculated (if
it hasn't already been) and the class precedence for subclasses
is frozen. An attempt to define a subclass whose included direct
supers would cause a difference class precedence ordering causes
an error to be signalled. An error is signalled if all superclasses
of the class argument do not have frozen class precedence lists
as well.