Issue 6540: Exception of strict evaluation (queries) (ocl2-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Author: Thomas Baar (thomas.baar@epfl.ch) Description: Strict evaluation for queries yields to contradictions in specifications Rationale: Queries can be specified in two ways, as invariants and in form of pre/post conditions. Suppose we specify query q(arg) as post: if (arg.oclIsUndefined()) then result = true else result = false endfi Having this, the following invariant should evaluate always to true: self.q(arg) = true or self.q(arg) = false. However, the invariant evaluates to undef once arg evaluates to undef thanks to strict evaluation. There is a misconception of strict evaluation when it comes to queries. The idea of queries is to have user-defined functions on classes. Why should the user be restricted only to such function which return undef once one of its arguments is undef? Using OCL, the user can even specify queries which can handle undefined arguments (e.g. see post specification of q(arg) ). Obviously, the post specification for q(arg) makes sense. The rule of strict evaluations for queries should be weakened to the case where the owner of the query (the object upon the query was called) is undefined. Resolution: This issue was raised before undefined was clarified as null and invalid. It is now permissible to pass null values to queries. Only invalid values cannot be passed. Disposition: Closed, no change Revised Text: Actions taken: November 10, 2003: received issue December 23, 2013: closed issue Discussion: Deferred for timing reasons End of Annotations:===== ption of strict evaluation (queries) Author: Thomas Baar (thomas.baar@epfl.ch) Description: Strict evaluation for queries yields to contradictions in specifications Rationale: Queries can be specified in two ways, as invariants and in form of pre/post conditions. Suppose we specify query q(arg) as post: if (arg.oclIsUndefined()) then result = true else result = false endfi Having this, the following invariant should evaluate always to true: self.q(arg) = true or self.q(arg) = false. However, the invariant evaluates to undef once arg evaluates to undef thanks to strict evaluation. There is a misconception of strict evaluation when it comes to queries. The idea of queries is to have user-defined functions on classes. Why should the user be restricted only to such function which return undef once one of its arguments is undef? Using OCL, the user can even specify queries which can handle undefined arguments (e.g. see post specification of q(arg) ). Obviously, the post specification for q(arg) makes sense. The rule of strict evaluations for queries should be weakened to the case where the owner of the query (the object upon the query was called) is undefined. Subject: Preparing 2nd ballot: Discussion regarding some other issues Date: Thu, 19 May 2005 19:34:42 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Preparing 2nd ballot: Discussion regarding some other issues Thread-Index: AcVcmQqSPJdP6R9nRLWNyrXiTmRKBw== From: "BELAUNDE Mariano RD-MAPS-LAN" To: Cc: "Jos Warmer" , X-OriginalArrivalTime: 19 May 2005 17:34:43.0877 (UTC) FILETIME=[0B454D50:01C55C99] Hi all, Below my comments and questions regarding some other issues that could be solved during second ballot. I will appreciate any contribution to solve this set of issues. 1) Issue 3513: Usage of qualifiers. This is an OCL1 issue that seems already be solved by OCL 2. Jos, since you are the author of this issue, could you check this and if possible send to me a resolution text? 2) Issue 4121 : Grammar for OCL. Internalization issue. Solved by OCL2 since is left intentionally undefined by the spec. 3) Issue 4451: Downcast OCL collection operators. My first impression is that the request is pertinent and can be easy solved by adding the missing operations to the Collection type in the standard library. Any opinion? Is there any volunteer to propose a resolution text? 4) Issue 5970: flatten I agree with Jos comments that two operations are needed (deepFlatten and flatten). Is there any volunteer for proposing the resolution text?. 5) Issue 5971: OrderedSet My feeling is that this issue has to be Deferred to the RTF because for timing reasons it will be very difficult to update in the FTF, in a consistent way, the semantics chapter. Unless someone's wants to take the issue ... 6) Issue 5973: what is a collection? Seems like the issue request for a mechanism to treat a user-defined class as a collection. Is there any opinion regarding the disposition for this issue? 7) Issue 6534: Up-and-down-casts with oclAsType() I don't understand the text of this issue. Has someone an idea what is the point here? (there is no 2.4.6 in the ptc document). 8) Issue 6535: Lack of operation specifications Unless someone is interrested to take this, I propose to defer it to the RTF (for timing reasons).. 9) Issue 6538: Exception of strict evaluation (implies) Unless someone is interrested to take this, I propose to defer it to the RTF (for timing reasons).. 10) Issue 6539: Exception of strict evaluation (forAll,exists) Unless someone is interrested to take this, I propose to defer it to the RTF (for timing reasons).. 11) Issue 6540: Exception of strict evaluation (queries) Unless someone is interrested to take this, I propose to defer it to the RTF (for timing reasons).. 12) Issue 6541: Exception of strict evaluation (=) Unless someone is interrested to take this, I propose to defer it to the RTF (for timing reasons).. Regards, Mariano