Re: [Dan Carnese <CARNESE@SPAR-20.ARPA>: Re: CLX draft 3 revisions

[Dan Carnese <CARNESE@SPAR-20.ARPA>]

    Date: 14 May 87 15:04 PDT
    From: Masinter.pa@Xerox.COM

    >As far as the appropriateness of prefixes, I think it's fair to say that
    >their use is a matter of personal style.  Since many people do find
    >prefixes useful, it is entirely appropriate to have them be a language
    >feature.  But I think it's also fair to say that if there were better
    >integration between the realizations of "class", "package", and "module" in
    >Common Lisp, the use of prefixes would be far less widespread.  I'm sure
    >this will happen -- it just hasn't happened yet.


    What did you have in mind?

Well, as an extremely naive approach, one could define a package for each
class which used the packages for each ancestor class.  Then whenever you
loaded a class definition, you automatically used the associated package.
The name of each generic function would be interned in (and by default,
exported from) the package associated with the most general class for which
it is defined.

Notice that this would require that for any individual name, a single most
general class must exist.  Thus, if we had a:height and b:height, where a
and b are unrelated classes, we could not define c as a subclass of a and b
without defining a new common superclass of a and b with which a unique
"height" would be associated.  This may be a good idea, but may also be a
bit draconian for some people's taste.  It also requires a symbol-merging
capability in the package system, so the old a:height and b:height symbols
would forward to the symbol associated with the new common superclass.

Futthermore, there probably needs to be at least three kinds of symbols in
these class-associated packages.  One of these would be for the "end-users"
of the class, one for the implementers of subclasses which make some
assumptions about the implementation (e.g., the semantics of some but not
all instance variables), and one which is private to the implementer of the
class itself.

With regard to modules, it seems clear that each module ought to be
associated with a package, which used and exported some or (by default) all
of the externals of submodules.  This might justify each class definition
and some or all of the generic functions of the class being implicitly
treated as a module.  Of course, this a different notion of module that is
not compatible with the current Common Lisp "compilation unit" idea.

There are certainly more issues that need to be raised and sorted out.  But
it seems likely that some reasonable proposal could be made.
-------