[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: CLOS-CONDITIONS (Version 2)
- To: Gregor.pa@Xerox.COM
- Subject: Re: Issue: CLOS-CONDITIONS (Version 2)
- From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Thu, 6 Oct 88 18:40 EDT
- Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-ERROR-HANDLING@SAIL.Stanford.EDU
- In-reply-to: <19881006222755.7.GREGOR@PORTNOY.parc.xerox.com>
Date: Thu, 6 Oct 88 15:27 PDT
Date: Thu, 6 Oct 88 16:27 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Changes per Moon's suggestions.
- I changed the way slot descriptions are handled.
This has the most chance of being controversial.
In the design of CLOS, we concluded that there were a lot of good
reasons not to do this automatic interning. It seems to me those
same good reasons apply here. It seems to me that doing the automatic
interning here introduces potential bugs, and makes the language as a
whole less elegant.
Why not just make people use exactly CLOS slot specifier syntax?
Because, unlike arbitrary classes, there are a lot of things you
do and don't normally do with conditions...
- Every slot in them is generally going to be readable.
- Every slot in them is generally not going to be writable.
- Every slot is going to need a way to be initialized, since
that's almost certainly the way they'll take on values.
Since nearly every use of conditions will involve the same set of
keys, I'm not sure I see that it's worth forcing people to do a
lot of work.
I'm very happy with having condition types be classes, etc. but I
think there's no reason to hit people over the head with that.
Also, it's no different than what DEFSTRUCT does, so it's not like this
is the only place in the language following those rules. Have you
submitted a proposal to deprecate DEFSTRUCT?
Finally, the main purpose of DEFINE-CONDITION is historical at this
point, so compatibility might as well matter. If you don't like it,
why don't you just always use DEFCLASS on CONDITION and avoid
Those are my reasons. I'll take your comment as a suggestion we
remove the compatibility. I'd like to hear from other vendors,
however, before I assume that your opinion (heavily CLOS-biased
as it is) is representative of the general community.
Whether I change the proposal will probably be based on what
others have to say. Even if you're the only one who thinks as you
do, though, it should be very easy for you to come to the meeting
with a slide to help you propose a modification before the issue
is brought to a vote. If people at the meeting are happy with the
change, I will be, too.