Re: Class Names (Again! Can't We Ever Stop?)

[Danny Bobrow <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
    benefit.
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.  

danny