[analyzer] Collection.getName() should include package qualification

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 241407 | | Status | NEW | | Importance | P3 normal | | Reported | Jul 18, 2008 10:56 EDT | | Modified | May 27, 2011 08:11 EDT | | Version | 1.2.0 | | Blocks | 318248 | | Reporter | Ed Willink |

Description

Given two classes m1::Class and m2::Class, a package containing Set(m1::Class) and also Set(m2::Class) fails in validateEPackage_UniqueClassifierNames, since the comparison is of Set(Class).

Collection.getName() should yield qualified names such as\ Set(m1::Class) and Set(m2::Class) unless it is known that the prefix is unnecessary.

[eclipse-ocl-bot]

By Christian Damus on Jul 18, 2008 22:53

How would it be known that the qualification of the name is unnecessary?

The OCL specification seems clear about the construction of the names of collection types, going to the extent of defining OCL constraints on the names. The element names aren't qualified. The problem is that

• Ecore requires unique classifier names in an EPackage, and
• the OCL spec doesn't suggest what should be the namespaces of demand-created\ collection types

In consequence, the default implementation of the OCL environment, which persists all collection types in a single package, trips over this constraint. So, I see two possible resolutions:

(a) suppress the unique-names constraint for OCL (it doesn't seem useful in an\ OCL context, anyway)\ (b) update the OCL environment's persistence of collection types to put them in\ namespaces structured according to the namespaces of the element types.\ I'm not sure how this should look for TupleTypes, which are complicated by\ the fact that they can reference multiple model classifiers

Preferences? I'm inclined to the former, especially as OCL collection types aren't intended to be generated to Java code (which is the reason for the uniqueness constraint); OCL collection types are, by definition, transient.

[eclipse-ocl-bot]

By Ed Willink on Jul 19, 2008 03:19

Short response: Very strong preference for refinement of the validation.

Long response: ...

UML requires that namespace elements satisfy an isDistinguishable() relationship and provides aliases and qualifications to help with import collisions. A simplistic unique name is clearly not the intent.

The OCL phrasing "The name of a set type is “Set” followed by the element type’s name in parentheses." could have been a loose usage of "element type’s name" that has been taken strictly.

It cannot be right that OCL imposes an algorithm that suppresses distinguishability. Therefore OCL should at least permit and recommend the use of qualification within Set names. ---> I'll raise an OCL issue.

Within Ecore, distinguishability and name difference are equivalent. It is the OCL extension that breaks the equivalence and so it is (MDT) OCL that must rewrite the validation constraint.

---

QVT has defined the package of Collections as a free choice so that\ A::Set(B) is the same type as C::Set(B). There is a suggestion that\ the package might be the container of the referencing context.

Migrating element qualifications to a packaging constraint seems very clunky.

---> I'll raise an OCL issue to propagate this upwards.

"OCL collection types are, by definition, transient."

I raised Issue 10946 last year suggesting that a CollectionTypeExp to support on the fly Collection Type construction.

[eclipse-ocl-bot]

By Christian Damus on Jul 19, 2008 14:18

(In reply to comment #2)

Short response: Very strong preference for refinement of the validation.

Long response: ...

UML requires that namespace elements satisfy an isDistinguishable() relationship and provides aliases and qualifications to help with import collisions. A simplistic unique name is clearly not the intent.

Yes, another point in which OCL and UML 2.0 are not well aligned.

The OCL phrasing "The name of a set type is “Set” followed by the element type’s name in parentheses." could have been a loose usage of "element type’s name" that has been taken strictly.

I actually was thinking of the OCL constraint in the well-formedness rules for the Types package:

context SetType \
inv: self.name = ?Set(? + self.elementType.name + ?)? 

which does not use 'self.elementType.qualifiedName'. The OCL constraints are meant to be taken literally ;-)

It cannot be right that OCL imposes an algorithm that suppresses distinguishability. Therefore OCL should at least permit and recommend the use of qualification within Set names. ---> I'll raise an OCL issue.

Except that OCL does not actually put the collection types into any package, so their distinguishability (or not) isn't well-defined. It's quite a large hole in the specification.

Within Ecore, distinguishability and name difference are equivalent. It is the OCL extension that breaks the equivalence and so it is (MDT) OCL that must rewrite the validation constraint.

The purpose of the Ecore constraints, as I understand them, is to ensure good code generation (for Java). That isn't applicable to OCL collection types, so probably disabling this constraint altogether is the way to go.

---

QVT has defined the package of Collections as a free choice so that A::Set(B) is the same type as C::Set(B). There is a suggestion that the package might be the container of the referencing context.

If I understand your comment correctly, CollectionTypes in QVT are implicitly members of the package containing the transformation that references them? That doesn't help the problem of the same transformation using Sets of p1::A and p2::A.

Migrating element qualifications to a packaging constraint seems very clunky.

Not sure I understand ... are you referring to option (b) from comment #1 ? That would be clunky, which is why I didn't recommend it.

---> I'll raise an OCL issue to propagate this upwards.

"OCL collection types are, by definition, transient."

I raised Issue 10946 last year suggesting that a CollectionTypeExp to support on the fly Collection Type construction.

I think your proposal needs an addendum to handle nested collection types. Any given CollectionTypeExp would have to either reference an element type from the model or contain another CollectionTypeExp for nesting. For example, a CollectionTypeExp for Set(Sequence(A)) would have to look like:

• CollectionTypeExp { kind = Set }
  • CollectionTypeExp { kind = Sequence, elementType = A }\ \ Besides, it doesn't address the problem of a collection type being referenced as the type of an expression, for example, an iterator. One could define OclExpression::type as a derived union of ownedType and referencedType properties, which would obviate the need for a CollectionTypeExp, but t wouldn't work in EssentialOcl. It would, however, be a solution that also addresses the same question for TupleTypes and MessageTypes.

[eclipse-ocl-bot]

By Ed Willink on Jul 20, 2008 02:24

Migrating element qualifications to a packaging constraint seems very clunky.

Not sure I understand ... are you referring to option (b) from comment #1 ?

Yes.

I raised Issue 10946 last year suggesting that a CollectionTypeExp to support on the fly Collection Type construction.

I think your proposal needs an addendum to handle nested collection types. Any given CollectionTypeExp would have to either reference an element type from the model or contain another CollectionTypeExp for nesting. For example, a CollectionTypeExp for Set(Sequence(A)) would have to look like:

• CollectionTypeExp { kind = Set }
  • CollectionTypeExp { kind = Sequence, elementType = A }

Besides, it doesn't address the problem of a collection type being referenced as the type of an expression, for example, an iterator. One could define OclExpression::type as a derived union of ownedType and referencedType properties, which would obviate the need for a CollectionTypeExp, but t wouldn't work in EssentialOcl. It would, however, be a solution that also addresses the same question for TupleTypes and MessageTypes.

Your observations blow my suggestion away. It's not worth rescuing.

[This discussion should be on the OCL mailing list, which I'm not on.\ If we agree on a better idea, I/you can at least sent a revising comment.]

How about introducing the concept of a transient type definition;\ a type contained by an OclExpression? Therefore the placement problem\ is solved by placing it in the referencing TypeExp/Iterator/... An\ OclExpression is not a namespace so distinguishability is not an issue.\ Equivalent transient (or ordinary) types are the same type.

[eclipse-ocl-bot]

By Christian Damus on Jul 20, 2008 19:46

(In reply to comment #4)

Your observations blow my suggestion away. It's not worth rescuing.

Oo, that's harsh ;-)

[This discussion should be on the OCL mailing list, which I'm not on. If we agree on a better idea, I/you can at least sent a revising comment.]

Yes, I can certainly do that.

How about introducing the concept of a transient type definition; a type contained by an OclExpression? Therefore the placement problem is solved by placing it in the referencing TypeExp/Iterator/... An OclExpression is not a namespace so distinguishability is not an issue. Equivalent transient (or ordinary) types are the same type.

Yes! I found myself thinking along exactly the same lines shortly after sending my last comment. However, I was looking at the ExpressionInOcl as a container for these transient types. It, also, is not a namespace and already contains vital context for the expression as a whole: the variable declarations of "self" and operation parameters. Moreover, there is only one ExpressionInOcl (which is intended as a top-expression) so there isn't any question of duplication of types or odd-looking cross-references in the AST.

If you're satisfied with that proposal, I'll be happy to circulate it around the RTF. Resolving this serialization problem would make me extremely happy.

[eclipse-ocl-bot]

By Ed Willink on Jul 21, 2008 02:09

ExpressionInOcl is no help to QVT, because QVT doesn't use it. QVT adds significant structural context to OCL. Expressions are used all over the place.

I fix up "self" by inserting it into a transformation environment.

To be useful to QVT, transient types need to be on OclExpression, or at least on those that could introduce a collection type.

The problem occurs wherever a type can be introduced: TypeExp or Variable rather than LoopExp. However since OclExpression is a TypedElement potentially any new derived OclExpression could introduce a type.

I'm inclined to think that the fix is as messy as the workaround (arbitrary package). The fix with changed AST will incur adoption delays, so I think it may be better to just define the workaround semantics accurately.

[eclipse-ocl-bot]

By Ed Willink on Sep 27, 2009 12:40

The ownership of CollectionTypes is resolved by Issue 10946 and covered by Bug 290654.

This Bug is therefore back to the original name distinguishabiilty problem that\ Set of m1::Class and Set of m2::Class share the same name Set(Class).

Options:

a) wontfix

validator reports errors on ambiguous collections\ users and possibly usages get unhelpful names

b) remove validation rule

needs an OMG UML Issue\ users and possibly usages get unhelpful names

c) always use qualified element types in collection names

always works\ needs an OMG OCL Issue\ may surprising existing usages

d) selectively use qualified element types in collection names

? is it possible to reliably identify ambiguous names that need a qualification ?\ if so, always works\ needs an OMG OCL Issue\ only surprises existing usages that were probably broken

---

I favour d) changing the names to Set(m1::Class) and Set(m2::Class) but only when Set(Class) would be ambiguous. If analysis shows that the potentially ambiguous test is infeasible revert to c) always qualifying all element names.

Either way we need an OCL rather than a UML issue.