Issue: CLOS-CONDITIONS (Version 4)

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Mon, 13 Mar 89 12:35 EST
    From: Richard Mlynarik <Mly@AI.AI.MIT.EDU>

	Date: Fri, 10 Mar 89 14:07 EST
	From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

	Proposal (CLOS-CONDITIONS:INTEGRATE):

	  1. Define that condition types are CLOS classes.

	  2. Define that condition objects are CLOS instances.

	  4. Define that slots in condition objects are normal CLOS slots. Note
	     that WITH-SLOTS can be used to provide more convenient access to the
	     slots where slot accessors are undesirable.

    This isn't any sort of clarification.  The actual clarification required
    -- which has been requested several times, and not just by myself -- is
    what the *METACLASS* of condition types is.

I do not agree that it is a -necessary- thing to specify the Meta-Class
of conditions because all intended uses of conditions can be done
without this information.

I agree that it is a -possibly useful- thing to do, but there is a down
side to it -- it would unnecessarily tie the hands of people who want
implementation flexibility for one reason or another.

I happen to like your idea of a READ-ONLY-CLASS, by the way.

I do not mind if someone proposes this change, but I do believe it is not
properly a part of the "essential changes" to integrate conditions with
CLOS. As such, I would prefer that it not be raised as part of this issue
because I don't want to risk this level of changes not going through due
to worry over that issue.

I would be happy to see you write up a separate proposal on the issue.
I can't guarantee that it will be accepted due to all the impending 
deadlines, but my vote will not be to table it on mere procedural grounds.
I can't speak for anyone else.

Please call the new issue CONDITION-META-CLASS.