Closed eclipse-ocl-bot closed 1 month ago
eclipse-ocl-bot
commented
1 month ago By Ed Willink on Sep 27, 2009 12:58
http://www.omg.org/issues/ocl2-rtf#Issue14357 provides an enhanced name syntax similr, but not identical, to the existing MDT OCL code.
14357 can be enhanced to accommodate QVTo-style/SQL-style doubling by defining
eclipse-ocl-bot
commented
1 month ago By Ed Willink on Oct 30, 2009 15:52
SQL-style doubling and concatenation is implemented by the patch on 292112.
eclipse-ocl-bot
commented
1 month ago By Ed Willink on Nov 12, 2009 02:54
Fixed by Bug 292112
eclipse-ocl-bot
commented
1 month ago By Ed Willink on May 27, 2011 02:46
Closing after over 18 months in resolved state.
| --- | --- | | Bugzilla Link | 287014 | | Status | CLOSED FIXED | | Importance | P3 enhancement | | Reported | Aug 19, 2009 02:19 EDT | | Modified | May 27, 2011 02:46 EDT | | Version | 1.3.0 | | Reporter | Ed Willink |
Description
OCL defines a number of ill-formed names for arithmetic operators such as "<".
These are defined directly in oclstdlib.ecore and oclstdlib.uml. No problem in UML; nearly 90 validation errors in Ecore.
User defined arithmetic operators can be defined in MDT/OCL 1.3.0 by e.g:
def: "<"() : = null
avoiding any lexical or parsing errors. The lexical bypass exploits the "" quoted backdoor originally put in before "_" prefixes were understood.
The above gives a Parser warning for non-standard usage, and a Validation error for a non-well-formed name.
There should be a mechanism for supporting at least the known ill-formed names without warnings or errors. Perhaps we have internally reserved names such as __less_than.
Should this mechanism support any valid UML name?
Should this mechanism be raised as an OMG Issue?
JUnit tests should be extended to cover user names. In particular I think there may be build in assumption that .not() and .<() return the standard rather than a user-defined Boolean.