Re: CLOS, and slot hiding.

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Tue, 5 Apr 88 15:05 est
    From: mike%acorn@oak.lcs.mit.edu (mike@gold-hill.com any day now)

	>I would like to be able to define a class that has certain advertised
	>behavior that I can advertise to users who will use it as a superclass
	>of their own defined classes, as a mixin. All I need to advertise are
	>the names, calling sequences and effects of some methods. As far as I
	>can tell, CLOS requires me to also advertise the names of the instance
	>variables that the methods use internally to contain state, so that
	>users can avoid name collisions when they define their own instance
	>variables.

    If the package system is really the only way to do this, then there
    is really a deep flaw in CLOS. It doesn't support classes for
    data-abstraction very well at all. Was this issue every discussed
    in the design of CLOS? 

Yes, it was discussed quite a bit.  Providing more information-hiding than
the package system provides was decided to be not a goal of CLOS, basically
because it's difficult.  Since the goals of CLOS have never been published,
this is my personal judgement, but I think the other members of the CLOS
working group would agree that this is a reasonably accurate statement of
the history.

Note that I am not claiming that CLOS provides excellent data abstraction
and I am not claiming that it would be useless to have explicit modularity
boundaries between subclasses and superclasses.  What I am claiming, and
there is plenty of support for this claim, is that standardization efforts
that do too much innovation beyond current practice generally fail.  CLOS
is a standardization effort, not primarily a research effort, and there is
no expectation that researchers won't develop a better language a few years
from now.  The purpose of CLOS is to satisfy the people who need a
standard, portable, efficient, well-documented object-oriented programming
language right now and can't afford to wait a few years.  I in fact think
that CLOS as it is went too far in the research direction and that is why
it's taken longer than expected and come out a little more incoherent than
we would like.

    I would like to submit this as an official comment on the draft CLOS
    spec (88-002) for x3j13. 

Fine.  I'm not sure if we've yet appointed anyone to be responsible for
collecting the official comments and making sure we have responses to them,
but this exchange of messages should be saved as part of that.

			     The class abstraction should support this
    kind of information hiding. The names of the instance variables
    should not be automatically inherited by the subclasses in every
    case. One must at least be able to override this default behavior and
    specify that certain instance variables are specific to the class and
    thereby avoid the name conflict problem with instance variables of
    subclasses.

I imagine that chapter 3 will provide the ability to extend the system in
this direction, if you define your own methods to replace enough of the
standard programmer interface.  Since chapter 3 is barely started at this
point, it's hard to make a definitive statement about that.