|Re: Custom static operation [message #1756460 is a reply to message #1756456]
||Fri, 17 March 2017 09:21
| Ed Willink
Registered: July 2009
7.5.10 is where most of the resolution of Issue 8937 was incorporated. Unfortunately the OCL 2.1/2.2 RTF report is not available to non-OMG members, so the text is appended below.
The specific issue of "::" and "." is clear. "::" means locate a name statically in a namespace, "." means navigate to the value of a name in an object, perhaps using a dynamic run-time mechanism.
I think what you observe is consistent with this.
(I do not find the application to allInstances() convincing, since either allInstances() must be both a static and a non-static operation to allow aPerson.allInstances() as well as Person.allInstances(), unless there is a magic reification of Person by a class object. In /org.eclipse.ocl.pivot/model/OCL-2.5.oclstdlib, allInstances is modelled as a static operation. In similar fashion to Java, static features of objects can be accessed dynamically.)
OMG Issue No: 8937
Title: Notation for accessing class operations is
International Business Machines (Dr. Tracy Gardner, <<email redacted>>)
The OCL 2.0 spec is inconsistent on whether class operations, including
predefined operations, should be accessed using '.' or '::' notation.
E.g. should it be Person.allInstances() or Person::allInstances()
The spec uses Person.allInstances() in the text, but the concrete
syntax specifies '::'.
It seems that most tools have adopted the '.' notation used in the
examples which is also backwards compatible with previous versions of
There has also been some adoption of the '::' notation, for example in
Warmer and Kleppe's OCL book, see:
Note: This issue was originally pointed out by Anthony Shuttleworth of
The '.' notation is widely used and backwards compatible with previous
versions of OCL. It should not be made invalid in OCL 2.0.
It may be appropriate to also support the '::' notation if this has
been widely adopted.
Accessing static features using '::' is unambiguously an invocation of a static property and not a property of
the Classifier metaclass. OCL's TypeExp is, effectively, a Classifier literal expression, so that the '.'
operator should invoke features of the Classifier metaclass. An example of this is allInstances(), which is
inherited from OclAny (which Classifier implicitly specializes) or allFeatures() (from UML).
The OCL text is updated to clarify that allInstances() is not a static operation
Update Section 7.5.10 "Features on Classes Themselves" to provide an example of a static operation on
Employee and to clarify that allInstances() is not a static operation:
All properties discussed until now in OCL are properties on instances of classes. The types are
either predefined in OCL or defined in the class model. In OCL, it is also possible to use static
features, applicable to the types/classes themselves rather than to their instances. For example, the
Employee class may define a static operation "uniqueID" that computes a unique ID to use in the
initialization of the employee ID attribute:
context Employee::id : String init:
Static features are invoked using the '::' operator and are distinct from the features of the Classifier
metaclass, which include the allInstances operation pre-defined by OCL. If we want to make sure
that all instances of Person have unique names, we can write:
context Person inv:
Person.allInstances()->forAll(p1, p2 |
p1 <> p2 implies p1.name <> p2.name)
Invocation of allInstances uses the '.' operator rather than '::' because it is not a static operation. It
is an operation applicable to instances of the Classifier metaclass, of which Person is an example.
Powered by FUDForum
. Page generated in 0.01644 seconds