[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Name That Class
- To: "David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Subject: Re: Name That Class
- From: kempf%hplabsz@hplabs.HP.COM
- Date: Mon, 10 Aug 87 12:15:15 MST
- Cc: common-lisp-object-system@sail.stanford.edu
- In-reply-to: Your message of Thu, 06 Aug 87 22:14:00 -0400. <870806221457.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
> As far as I am concerned, any of these three would work. My objection
> to solution 3 is primarily that it is more complicated.
In addition to this objection to solution 3, another is that while other things
(particularly functions) can be multiply named, there
is currently no portable way in CL to get the name (or names) of
a function given a function definition object. If we are going to model
class object naming similarly to function naming (as the name SYMBOL-CLASS
seems to indicate) then we should probably be consistent with the way
functions are done, or suggest that a FUNCTION-NAME or a FUNCTION-NAMES
function be introduced which provides similar functionality; otherwise,
people may become confused. But see below for further thoughts.
> ....
> (setf (class-named 'n1) nil)
> #<Standard-Class N2 1>
> Is this really how we want to undo these bindings? Nothing else in Common
> Lisp I can think of works this way (storing nil). Also, a minor nit, CL
> requires that such a setf form return nil, not the former value.
> I think its easy to see how this whole thing would work for
> generic-function-name, symbol-function, setf of symbol-function,
> get-setf-generic-function and setf of get-setf-generic-function.
> Agreed. Note that (setf (symbol-function 'foo) nil) isn't how we do
> (fmakunbound 'foo) in CL currently.
Your observation about undoing bindings is correct, and, again, to maintain
consistency, CMAKUNBOUND would be the way do this if class name to
object binding is modelled on function name to object binding.
We seem to be slowly drifting towards using a name to object binding
for classes which is modelled on the way function name to object bindings
are handled. I wonder how useful the function model is for modelling
class name to object bindings. In particular, is this going to lead to
the proposal of a "class cell" like the "function cell" for a symbol?
Considering the controversy surrounding the latter, I certainly hope not.
Somehow, I would prefer a more object-oriented approach to resolving this
problem. Two ways which I can think of offhand are:
1) Have the class name be a SETFable slot in the class object. SETFing
a class object's name slot to NIL would be equivalent to making the class
anonymous, if we abide by the convention that asking for the name of
an anonymous class returns NIL (as was discussed in another note string).
2) Have the name to class object binding for an entire class be handled
by the metaclass protocol.
Of the two, I prefer the second one, since it gives some flexibility
for users wanting to define new metaclasses, and also gives some potential
for resolving the compile time name to object mapping, since the metaclass
can potentially control this, but perhaps in an implementation dependent
manner.
I'm willing to write up a proposal on this, if there is any interest.
Though I prefer a more object-oriented approach, I think it is important
that the name to object mapping issue be resolved in a way that is self
consistent and consistent with the rest of Common Lisp.
jak