From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,c52c30d32b866eae X-Google-Attributes: gidfac41,public X-Google-Thread: 1108a1,c52c30d32b866eae X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,2ea02452876a15e1 X-Google-Attributes: gid103376,public From: tynor@atlanta.twr.com (Steve Tynor) Subject: Re: Real OO Date: 1996/05/15 Message-ID: #1/1 X-Deja-AN: 154948021 sender: tynor@atlanta.twr.com (Steve Tynor) references: organization: Tower Technology newsgroups: comp.lang.eiffel,comp.lang.ada,comp.object Date: 1996-05-15T00:00:00+00:00 List-Id: In article bobduff@world.std.com (Robert A Duff) writes: | However, I find the definition of "Availability of an Assertion Clause" | in that section confusing. Is it not the case that pre-conditions are | always "available"? "Availablity" relates to the "export status" of each feature. If I write: feature {ANY} f is require a > b do .. end a : INTEGER feature {NONE} b : INTEGER VAPE requires that both `a' and `b' are exported to all possible clients of feature `f'. In this case, `a' is available to all the clients of `f' (since it is exported to the same set of classes: {ANY}), but `b' is not. Therefore the precondition is invalid. It's a pretty intuitive concept: it's not reasonable to base a precondition (which imposes constraints on the client) on features which the client has no way of checking for itself. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= You can always sleep in your car, but you can't take your house for a drive. Steve Tynor Email: Steve.Tynor@atlanta.twr.com Tower Technology WWW: http://www.twr.com/