[ast] Eliminate CollectionLiteralExp.kind

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 297390 | | Status | NEW | | Importance | P3 normal | | Reported | Dec 09, 2009 15:00 EDT | | Modified | Feb 06, 2014 02:18 EDT | | Blocks | 318248 | | Reporter | Ed Willink |

Description

Implement the suggested elimination of CollectionLiteralExp::kind from OMG Issue 13225.

[eclipse-ocl-bot]

By Ed Willink on Dec 09, 2009 16:56

Eliminate CollectionType.kind too.

[eclipse-ocl-bot]

By Ed Willink on Dec 16, 2009 18:05

CollectionType.kind is already transient and volatile. Making it derived too changes only comments. Deprecating it causes about 15 warnings in OCL and 10 in QVTd. It's a convenient utility method, so why lose it?

CollectionLiteralExp.kind or more particularly setKind() supports a lazy coding practice wherebt the kind is determined and used later to determine the type. Making this deroved and readonly causes 2 OCL errors and 21 test errors. These should all be easy to fix, so we can change it to derived. getKind() is used about 15 times so could be eliminated, but it is also a convenient utility method, so why lose it?

Therefore let both be derived readonly properties.

[eclipse-ocl-bot]

By Radomil Dvorak on Dec 16, 2009 18:40

(In reply to comment #2)

CollectionType.kind is already transient and volatile. Making it derived too changes only comments. Deprecating it causes about 15 warnings in OCL and 10 in QVTd. It's a convenient utility method, so why lose it?

Just to make CollectionType extensible.\ Though, it should not be a big deal to define utility methods based on eClass values.

CollectionLiteralExp.kind or more particularly setKind() supports a lazy coding practice wherebt the kind is determined and used later to determine the type. Making this deroved and readonly causes 2 OCL errors and 21 test errors. These should all be easy to fix, so we can change it to derived. getKind() is used about 15 times so could be eliminated, but it is also a convenient utility method, so why lose it?

Therefore let both be derived readonly properties.

Well, I did not expect this would just be a plain deletion.\ Could MDT OCL specify then a contract for extending collection types to be\ safe if these features are kept?

[eclipse-ocl-bot]

By Ed Willink on Dec 17, 2009 02:31

After considering the getKind() methods as harmless utility methods, I wondered whether to provide the more useful isOrdered() and isUnique() utility methods as well.

Perhaps the true redundancy is CollectionKind and all its uses. The enumeration is not extensible and not very useful.

In OCL expressions it is the four combinations of isOrdered and isUnique (and possibly isAbstract) that are interesting; tests are always a laborious encoding of isOrdered as if OrderedSetType or SequenceType.

CollectionKind gives a restrictive encoding that tends to make provision of another collection type awkward, though I'm not sure there are more than four options. QVTo's List is just an alternative implementation of Sequence.

Perhaps we could eliminate CollectionKind, add new abstract OrderedCollection, NonOrderedCollection, UniqueCollection, NonUniqueCollection 'classes' so that OrderedSet extended {OrderedCollection, UniqueCollection} and collection methods were introduced consistently. A type test could then identify that OrderedCollection::at(1) was a valid invocation. This would remove needless Sequence/OrderedSet, Set/OrderedSet asymmetries.

For compatibility, the CollectionKind value can be synthesized from isAbstract, isOrdered, isUnique.

A genuinely new style of Collection could then be introduced that extended perhaps UniqueCollection but neither form of OrderedCollection nor NonOrderedCollection. It would have a null CollectionKind.

Would this give the flexibility you are looking for?

Aha! the collection 'kinds' encode characteristics of MultiplicityElement.unique, ordered, and also lower, upper.

Why shouldn't I define an OrderedTriplet, NonOrderedPair, or a Singleton? The proposal above allows it. OrderedTriplet::add would be invalid on evaluation, though perhaps making add an operation of ExtensibleCollection and not of NonExtensibleCollection would give a useful third dimension; so OrderedSet extends {OrderedCollection, UniqueCollection, ExtensibleCollection}. NonExtensible is an encoding of 'readonly'.

[eclipse-ocl-bot]

By Radomil Dvorak on Dec 18, 2009 15:45

(In reply to comment #4)

CollectionKind gives a restrictive encoding that tends to make provision of another collection type awkward, though I'm not sure there are more than four options. QVTo's List is just an alternative implementation of Sequence.

I suspect that any kind of assumptions that lead to a limited number of collection types which are found useful at the moment results in more or less\ the same problem. One day someone may need a Queue and we get to the same point.

Perhaps we could eliminate CollectionKind, add new abstract OrderedCollection, NonOrderedCollection, UniqueCollection, NonUniqueCollection 'classes' so that OrderedSet extended {OrderedCollection, UniqueCollection} and collection methods were introduced consistently. A type test could then identify that OrderedCollection::at(1) was a valid invocation. This would remove needless Sequence/OrderedSet, Set/OrderedSet asymmetries.

The QVTo ListType extends CollectionType and I'm OK with that, besides I do not need to invent here, OMG states that. I think what is needed is to be able to extend any of the known OCL collection types, so all the behavior defined for these should work for the new types as well.\ Enum as non-extendable is not useful here, I would just replace it by whatever else what can be extended and can represent the corresponding type.\ Perhaps even a wrapper class encapsulating the value of Class<? extends CollectionType<?,?>>.

For compatibility, the CollectionKind value can be synthesized from isAbstract, isOrdered, isUnique.

A genuinely new style of Collection could then be introduced that extended perhaps UniqueCollection but neither form of OrderedCollection nor NonOrderedCollection. It would have a null CollectionKind.

Would this give the flexibility you are looking for?

Well, no need for extra portion of flexibility, what is essential is to avoid\ OCL code that makes mandatory usage of hardcoded decisions based on fixed CollectionKind, like CollectionUtil.createNewCollection(CollectionKind) etc.\ If an extensible "kind" element is defined and used in OCL identically, along with delegation to client defined extensions, I guess all extenders might be happy. \ The compatibility CollectionKind value might be of the OCL predefined super type being extended, so we could avoid null. The OMG OCL model does not define it, could that be only at Java code level?

Aha! the collection 'kinds' encode characteristics of MultiplicityElement.unique, ordered, and also lower, upper.

Why shouldn't I define an OrderedTriplet, NonOrderedPair, or a Singleton? The proposal above allows it. OrderedTriplet::add would be invalid on evaluation, though perhaps making add an operation of ExtensibleCollection and not of NonExtensibleCollection would give a useful third dimension; so OrderedSet extends {OrderedCollection, UniqueCollection, ExtensibleCollection}. NonExtensible is an encoding of 'readonly'.

I'm not sure I can follow ;). I have fairly limited usecase.

[eclipse-ocl-bot]

By Ed Willink on Dec 19, 2009 10:28

Radek: I'm very confused about your response.

This Bugzilla started as a request to prototype your OMG Issue 13225 eliminating CollectionLiteralExp::kind.

My analysis indicated that so long as CollectionKind exists, CollectionLiteralExp::kind and CollectionType::kind are useful convenience derived methods.

CollectionKind as an enumeration is not extensible; hence the extensibility problem.

I provided a proposal to replace CollectionKind by a number of behavioural dimension and associated behaviours.

I would like you to comment on the proposal so that we can refine it or proceed in another direction.

---

Instead you raise other issues.

Queue is indeed an alternate form of collection, and from an imperative perspective, the difference may be important. OCL is declarative so constraints that express truth about the contents of a Queue are indistinguishable from those that express truth about the contents of a Sequence.

CollectionUtil.createNewCollection(CollectionKind) is an implementation detail of MDT/OCL that may merit revision, but is not relevant to how CollectionKind should evolve. Once CollectionKind has a new definition, revised CollectionUtil support may follow.

Pair etc, were my attempt to identify alternate forms of collection. If a Pair is treated as just a fixed length Sequence, aPair->add(x) would be valid. However if a Pair is a first class collection, aPair->add(x) would be diagnosed as invalid, requiring aPair->asSequence()->add(x) to cast away the fixed dimension of two. Fixed size is a Collection behaviour that might merit capturing in a more flexible declarative type system. The end-only access of a Queue is not so clear cut; though it would do no harm for a better solution to capture it too.

---

If you don't understand my proposal, please request clarification.

[eclipse-ocl-bot]

By Radomil Dvorak on Dec 19, 2009 14:18

(In reply to comment #6)

I would like you to comment on the proposal so that we can refine it or proceed in another direction.

I have tried. Sorry, if I have caused confusion.\

Instead you raise other issues.

I did not intend to raise other issues, I still see a single one, a general extensibility of collection types.\

If you don't understand my proposal, please request clarification.

My concern is to implement collection type extensions defined by OMG QVT specification. QVTo has done that in some way, but I do not feel much safe here, as there is no clear contract from MDT OCL yet.\ I sort of assumed that fixing this bugzilla would solve the problem, as OCL\ would come up with whatever solution which eliminates the restrictive collection kind.\ Though you might find this out of the scope of this SCR, the clarification I need is "how to extend collection types correctly", in case MDT OCL decides to support it.

[eclipse-ocl-bot]

By Ed Willink on Nov 08, 2011 04:47

The new pivot code retains CollectionLiteralExp::kind for compatibility but never uses it.

[eclipse-ocl-bot]

By Ed Willink on Feb 06, 2014 02:18

The purpose of CollectionLiteralExp.kind is to allow a single AS class to initialize many run-time collections. As such it is not redundant. (It is Collection.kind that is redundant).

To make CollectionLiteralExp.kind extensible and so eliminate QVTo's ListLiteralExp we need to redefine it from an enumeration to, in Java terms, Class. QVTo can then specify ListType.class.

We can model 'Class<? extends CollectionType>' weakly as just Class, or more strongly as Metaclass(CollectionType).