|
| Re: When to use . and -> [message #1848746 is a reply to message #1848739] |
Wed, 15 December 2021 20:32   |
 Christopher Gerking
Messages: 115
Registered: April 2011 |
Senior Member |
|
|
Hi Jan
Let's hope that I will get it right. In general, the . operator is used to access properties or invoke operations of a single element, just like you would do in Java. The -> operator is used to invoke a predefined operation (such as collect, select, etc.) on a Collection of multiple elements. These are the general rules, depending on whether the variable on the left is a single element or a Collection. You can read about these rules in section 7.4.10 "Navigation Operators and Navigation Shorthands" of the OCL specification.
However there are also generalizations of these rules. First, you can also use -> operator on a single element. This will implicitly convert that element into a Set, before invoking the specified operation on that Set. Second, you can also use . operator on a Collection. This will implicitly access the specified property (or invoke the specified operation) of each element in the Collection, before collecting the results in a single flattened Collection.
As you can see, it's already quite confusing. It gets even worse if you take into account the use of -> as a collect shorthand. As stated above, OCL uses -> to invoke a predefined collection operation. However in QVTo you can also use -> to invoke an operation of the single elements in the given collection (or access one of their properties). The results will be collected using the xcollect operation. For example, as described in the QVT specification, list->prop is a shorthand for list->xcollect(i | i.prop), leading to a Sequence of all property values.
Kind regards
Christopher
[Updated on: Thu, 16 December 2021 08:18] Report message to a moderator |
|
|
|
|
| Re: When to use . and -> [message #1848772 is a reply to message #1848762] |
Thu, 16 December 2021 12:34 |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi Christopher
Ok, when I read your words again, they are not actually wrong, just confusing. It is much simpler to first define the two clean cases, then the two short forms that rewrite using the clean cases.
OCL 2.4 introduced the oclAsSet() operation in order to avoid the previous inconsistent magic (4 conversions were to Set and one to Bag)
anObject->aFeature is a short form that is 100% equivalent to anObject.oclAsSet()->aFeature
similarly
aCollection.aFeature is 100% equivalent to aCollection->collect(aFeature)
These are not generalizations. They are short forms / pragmatic use of a gap in the syntax.
Your use of "predefined operation" confuses me. I do not recognise any difference short form-wise between an operation that is defined by the OCL standard, the QVTo standard, a user model, a Complete OCL model or a QVTo helper. They are all operations to which the short forms apply.
(The Pivot-based OCL parser performs precisely the above translation so that oclAsSet / collect is present in the AST and executed as such avoiding the need for magical conversions in other places.)
The QVTo usage is a problem that I was not aware of / forgotten. If QVTo is compatible with OCL then QVTo cannot redefine the implicit collect short form as implicit xcollect. If QVTo does redefine, then there should be a very clear incompatibility statement. From a practical point of view, even implicit collect in OCL is bad, an implicit xcollect in QVTo is worse, since the only point of the "x" is to allow some nasty breaks , continues, raises or returns for which I think the usage really should be pretty explicit even if it could perhaps be statically analyzed
Regards
Ed Willink
|
|
|
Powered by
FUDForum. Page generated in 0.03102 seconds
] 
Search
Help
Register
Login
Home
