cowan_at_ccil.org writes:
> This poor man's multiple inheritance makes it messy and awkward to add a
> new type to an existing condition. If the existing condition is simple,
> one must create a compound condition containing the new and the existing
> condition; but if it is compound, one must unwrap the compound condition,
> create a new condiion, and rewrap all the simple conditions into a new
> compound condition. In either case, properties will not be lost but
> may be shadowed.
There's all kinds of "must" language in here, but I don't even
understand what you're trying to do. I suspect your complaint is
based on misunderstandings of or ambiguities in the spec. Could you
clarify, possibly with some code fragments? (Note that both simple
and compound conditions are are conditions. None of the procedures
operating on conditions is restricted to one or the other.)
> The make-condition-type, condition-type?, make-condition, and condition?
> procedures and the define-condition-type syntax are unchanged.
> The condition-has-type? procedure applies only to the condition itself,
> not to its wrapped condition.
We considered designs like this during the editors' discussion (I
believe Java has something similar), but this would considerably
weaken the protocols that could be implemented using conditions. In
particular, it is often desirable that a condition belongs to several
condition types, and the layout of R5.92RS's condition types assumes
this in many places.
Other than this crucial aspect, the model you propose doesn't seem to
be all that different from the one in R5.92RS: You have an ordered
chain of "primitive conditions", R5.92RS essentially has a list of
simple conditions.
--
Cheers =8-} Mike
Friede, V?lkerverst?ndigung und ?berhaupt blabla
Received on Sat Feb 10 2007 - 11:13:33 UTC