[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: common-lisp-object-system@SAIL.Stanford.EDU
- Subject: D'4 Example
- From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
- Date: 23 Mar 88 1314 PST
``Is this really a good example of an element of D'4?''
I think it is, but I'm probably thinking of a different situation than
Dave is. If the two classes are similar somehow, such as making the class
of some instance be HONDA-ACCORD when it used to be HONDA-PRELUDE, then it
makes sense to extend CLOS to ``make it work.'' But there is nothing to
prevent someone from changing the class of some instance from
BALLISTIC-TRANSISTOR to MOJO-HAND. In this case what does it mean to be in
a method selected on the basis of the inherent characteristics of an
instance of BALLISTIC-TRANSISTOR when those characteristics all change? If
there are two inheritance chains whose only common superclass is T, it is
not unreasonable to find that the slot names defined by a pair of classes,
one in each chain, could be the same. An implementor could ``make it
work'' that slot accesses to same-named slots could not suffer a
conniption, but what would such accesses mean?
It is reasonable to require that when execution is lexically within some
method, that the author of the method can count on the basic identity of
the instances on the basis of which it was selected to not change. Those
characteristics *might* change, so we do not want to detect such changes,
but for the implementor to mandate some behavior in this bizarre case is
beyond the reasonable scope of his work. Thus even the statement of what
it would mean to extend CLOS to this situation is senseless.
If the class of some instance radically changes (according to the author's
ontology), the meaning of a method that continues while such a change
happens is as stable or sensible as if the names of the slots in that
instance were instantly permutted while the actual offsets used by the
method remained the same. Thus, you could make it work, but you couldn't
make it make sense.
The new wording solves this problem by letting implementors go to
extremes to make it work, while we've told the users to ignore
the work done by the implementors.