[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
comments on CLOS draft 88-2
- To: "mike@gold-hill.com any day now" <mike%acorn@LIVE-OAK.LCS.MIT.EDU>
- Subject: comments on CLOS draft 88-2
- From: Gregor.pa@Xerox.COM
- Date: Fri, 8 Apr 88 13:12 PDT
- Cc: common-lisp-object-system@SAIL.STANFORD.EDU, mike@LIVE-OAK.LCS.MIT.EDU
- Fcc: BD:>Gregor>mail>outgoing-mail-2.text
- In-reply-to: The message of 8 Apr 88 11:13 PDT from "mike@gold-hill.com any day now" <mike%acorn@LIVE-OAK.LCS.MIT.EDU>
- Line-fold: no
I believe that the philosopy behind the suggestion is a good one, but I
don't think this particular instance applies.
The reason is that I don't see instance updating as a development
environment only issue -- the reason we put updating in was that we
didn't see it as a development environment only issue.
Imagine a piece of product code which defines a bunch of classes, call
it Product1. Now imagine another product which is an extension to the
first product, call that Product2. It is reasonable to assume that
Product2 will want to modify some aspects of Prodcut1. Specifically,
Product2 may want to modify some of Product1's class definitions. The
instance update protocol is designed to make this kind of scenario
workable. I think having this kind of flexibility is going to be real
important to unbundled products which use CLOS.
Another important point is that the CLOS committee understands the cost
of having this kind of flexibility quite well. It is minimal. I don't
think that this feature complicates the implementation of CLOS
significantly.
-------