[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Class Names (Again! Can't We Ever Stop?)
- To: RPG@SAIL.Stanford.EDU
- Subject: Re: Class Names (Again! Can't We Ever Stop?)
- From: Danny Bobrow <Bobrow.pa@Xerox.COM>
- Date: 2 Feb 88 17:57 PST
- Cc: common-lisp-object-system@SAIL.Stanford.EDU
- In-reply-to: Dick Gabriel <RPG@SAIL.Stanford.EDU>'s message of 02 Feb 88 14:01 PST
- Sender: Bobrow.pa@Xerox.COM
The topic of naming objects in CLOS is addressed by an entire
level of the meta-object protocol. I see no reason to introduce
gratuitous and unmotivated generalizations into the base level when
someone who wants to introduce a bizarre naming scheme will have
all the mechanism laid at his feet with which to do it.
There is no mechanism to handle names for classes specified in the metaobject
protocol other than symbol-class and class-name. It is for this reason that one
wants not to restrict the values of class-names.
It introduces a bit of generality for which very few people
will imagine a use, and while doing so it increases the complexity
of an already too-complex specification that already has mechanisms
to handle naming. In short: epsilon complexity increase, zero
This removes a restriction rather than introducing a generality. The only
property of symbols that is used, as far as I can see, is the ease of typing
something in that will be EQL each time. With the EQL restriction on how names
refer to classes, I see neither an implementation problem nor a conceptual one.
Those users who can never think of a use for this feature will never have to
encounter it (it never interferes). We have used this feature extensively for
dynamically constructed class combinations, with mixins selected from carefully
selected orthogonal sets, where to have to have a symbol for a name causes
construction of long ugly concatenations.