[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Miscellaneous decisions taken or to be taken
- To: firstname.lastname@example.org
- Subject: Re: Miscellaneous decisions taken or to be taken
- From: Patrick H Dussud <DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET>
- Date: Thu, 30 Jul 87 07:57:57 CDT
- Cc: common-lisp-object-system@SAIL.STANFORD.EDU
- In-reply-to: Msg of Wed, 29 Jul 87 16:25:25 -0700 from email@example.com
> We need to decide whether class-name of an anonymous class is nil.
Two choices are 1) NIL 2) CLASS-NAME signals an error. I vote for the
second. An anonymous class should be a class with NO name.
If we signal an error on class-name, then we have to come up with a
predicate to test if the class is named or not. Is it worth the trouble?
Additionally, it would be nice if
top level forms would also print out something at compile time. Our
applications developers are asking for some feedback about what gets
done at compile time. Maybe that's an implementation issue, though.
You're right, it is an implementation issue, some compilers have a
> 2-13 class-named needs a new name for consistency. get-class would be wrong
> because the other get-xxx functions aren't name operations. symbol-class
> is the agreed name. It needs an environment argument. The errorp argument
> gets in the way. I think we agree that symbol-class should be setf'able,
> but can it only be set once for a given symbol or is it allowed to change
> the symbol-to-class-object mapping?
Why an environment argument? Since we haven't agreed to lexically scoped
class names, this would seem unnecessary. Is it to deal with the ERRORP
argument? Why do people think it will get in the way? Why not just make
it a keyword argument? A user might want to not have it signal an error
especially in metaclass programming. If whether or not it signals an
error is dependent on a (second-class) environment argument, then it
will be more difficult for a user to arrange. I think the name SYMBOL-CLASS
is OK, and that it should be allowed to change the
The important thing in CLOS is the object, and the name to object mapping
should be changable.
The environment argument will be necessary to address the compile
environment problem. The term might be confusing, it is not necessary
an environment like the &environment argument in a macro definition.
> What can be done with method objects, e.g. can one method be added
> to more than one generic function?
There may be a problem if the method invokes CALL-NEXT-METHOD. This
relates back to whether CALL-NEXT-METHOD is dynamic or indefinite
in extent. If it is dynamic, then there should be no problem, since
the binding of CALL-NEXT-METHOD is done when the method begins executing,
at the latest, or during calculation of the effective method, at the
earliest. Thus the same method object on multiple generic functions
would be no problem, since that case could be detected and establishment
of CALL-NEXT-METHOD's binding deferred as late as possible. If the
extent is indefinite, then the binding could potentially remain outside
of a particular method invocation, and so adding the same method to
more than one generic function may cause a problem.
> Which symbols defined by the standard go in what package?
> July: I think we said some will go in LISP: and some will go in CLOS: and
> we don't know yet where to draw the line.
I think they should all go into CLOS, except those which are already in
LISP (like DOCUMENTATION) or those which are designed to replace aspects
of LISP already existing (like PRINT-OBJECT). Very few are in these categories.
We said that some of the symbols will go to LISP because CLOS is
supposed to be part of ANSI Common Lisp. The top level macros and
functions should be part of LISP. The internal functions specified for
the sake of metaclass programming can reside in CLOS.
> Gregor doesn't like the ability to specify constraints on the ordering
> of classes that only apply conditionally, i.e. if those classes are
> actually present among the superclasses. He considers this bad style.
> Moon volunteered to write a proposal with some examples, and we agreed
> to resolve this over the mail.
I agree with Gregor. I think that user specified changes in the CPL
should be controlled through COMPUTE-CLASS-PRECEDENCE-LIST, or, if
the default algorithm can't make a decision.
Let's see what Moon's proposal before discussing the issue.
> I'm not sure if we said anywhere what happens when you call a generic
> function and there is no applicable method; I think it ought to signal
> an error.
Yes, and CALL-NEXT-METHOD should do the same. Again, we need to clarify
in the context of Dick's proposed error naming scheme.
If we can assume that the ANSI will standardize an error handler then I
am in favor of signalling an error and specifying the signal name. If
we can't assume that, I would rather call a generic function like