Update QVT models to QVT 1.1, OCL 2.1

[eclipse-qvt-oml-bot]

| --- | --- | | Bugzilla Link | 295316 | | Status | ASSIGNED | | Importance | P3 normal | | Reported | Nov 17, 2009 01:48 EDT | | Modified | Dec 10, 2009 05:04 EDT | | Version | 2.0 | | Depends on | 290654 | | Reporter | Ed Willink |

Description

OCL 2.1 has a TemplateParameterType very closely resembling ImperativeOCL's.

In preparing the models for QVT 1.1, I am therefore removing the ImperativeOCL variant.

I will update all the plug-ins to 3.0.0 and JDK 6.

Any other changes pending?

[eclipse-qvt-oml-bot]

By Radomil Dvorak on Nov 17, 2009 06:03

Ed, I do not want to break compatibility to JDK 5. I do not think that \ EOSL of JDK 5 should mean to stop running applications that are still bound to JDK 5 for whatever reason.

If OCL 3.0 decides to do that we have to follow but I hope it will not \ happen.

No changes pending in ImperativeOCL.

[eclipse-qvt-oml-bot]

By Ed Willink on Nov 20, 2009 15:45

Created attachment 152756 Update to QVT 1.1 models

Attached seemingly huge patch just moves TemplateParameterType to EssentialOCL, and adds ListLiteralExp, uses org.eclipse.ocl.edit from MDT/OCL, updates to 3.0.0 for QVTo and 0.8.0 for QVTd.

The patch is unable to cope with the deletion of 700-odd creation icons (icons/full/ctool16 in each edit plugin). These were just bloat that I've switched off in the genmodel. Please delete by hand.

Regeneration adds some $NON-NLS markers.

Still Java 1.5.

The OMG QVT 1.1 models are derived from the same models that the JUnit tests check the consistency of, so there is a very good chance that these models are exactly QVT 1.1.

:notepad_spiral: Bug295316b.patch

[eclipse-qvt-oml-bot]

By Ed Willink on Nov 20, 2009 15:46

[Now that I'm the de facto QVTd leader, I should have access to the QVTd releng, so I can get the QVTd builds to work; it is now my top priority.]

[eclipse-qvt-oml-bot]

By Ed Willink on Dec 09, 2009 05:00

The TemplateParameterType is in MDT/OCL 3.0.0M4 and QVTd CVS is compatible.

It would perhaps be better not to have a rival ImperativeOCL::TemplateParameterType in QVTo M4 and beyond.

[eclipse-qvt-oml-bot]

By Radomil Dvorak on Dec 09, 2009 09:21

Thanks Ed for the path. Actually, I have committed those plugins depending on QVTd blindly as I do not have time to struggle with dependencies at the moment, \ so please check if all is fine for you.

As for ListLiteralExp, I see this class rather problematic then serving any reasonable purpose.\ Initially introduced http://www.omg.org/issues/issue14620.txt is solved but the core extensibility problem remains.\ I submitted an issue to OCL http://www.omg.org/issues/issue13225.txt but it\ was deferred due to some (for me) implementation specific problem, leaving this area inconsistent. A single CollectionLiteralExp class could be used, IMO.

Additionally, MDT OCL has introduced CollectionType::kind attribute, which though transient and not serialized, is just there and is used in a couple of places. This is the main obstacle I can see in extensibility of OCL collection types.

Also, I wonder why ListLiteralExp does not use CollectionLiteralPart. Would\ be nice to reuse existing initialization mechanism for collections.

[eclipse-qvt-oml-bot]

By Ed Willink on Dec 09, 2009 15:02

Mariano asked me to produce the models at quite short notice, so I reviewed the oustanding OCL and QVT changes and produced the models that are now those provided by OMG.

ExpressionInOCL.generatedType was a trivial addition.

TemplateParameterType was a simple move.

ListLiteralExp was badly specified as a CollectionLiteralExp derivation causing problems with the semantics of the CollectionLiteralExp members. Mariano agreed this was a mistake, so there is an issue raised to change the inheritance to LiteralExp which is what the patch realises. ListLiteralExp certainly could be replaced by a CollectionLiteralExp, at the expense of a layer of part objects. QVTo has quite a lot of sugar. As a new class, ListLiteralExp should cause no problems until any existing workaround is replaced.

Your CollectionLiteralExp::kind Issue is one I've given only a little thought to. Mainly wondering whether changing the attribute to derived will preserve compatibility or not for existing serialisations. The attribute is redundant and so should cause no problems apart from bloat. MDT/OCL hasn't introduced it; It has implemented what is (redundantly) specified. While we're changing the major MDT/OCL version could be a good time to lose it. I've raised Bug 297390.

These changes have no impact on QVTd. It's just that in my role as model provider to QVT, I try to provide the full set of models.

[eclipse-qvt-oml-bot]

By Radomil Dvorak on Dec 09, 2009 16:42

(In reply to comment #6)

ListLiteralExp was badly specified as a CollectionLiteralExp derivation causing problems with the semantics of the CollectionLiteralExp members. Mariano agreed this was a mistake, so there is an issue raised to change the inheritance to LiteralExp which is what the patch realises. ListLiteralExp certainly could be replaced by a CollectionLiteralExp, at the expense of a layer of part objects. QVTo has quite a lot of sugar. As a new class, ListLiteralExp should cause no problems until any existing workaround is replaced.

Your CollectionLiteralExp::kind Issue is one I've given only a little thought to. Mainly wondering whether changing the attribute to derived will preserve

You can customize resource loading so missing feature gets ignored.

compatibility or not for existing serialisations. The attribute is redundant and so should cause no problems apart from bloat. MDT/OCL hasn't introduced it; It has implemented what is (redundantly) specified.

I have talked about CollectionType::kind, I can't see it in the spec, so assume MDT OCL has introduced it. To me, it's equally redundant and introduces the same kind of issue for extensibility.

Again, It's clear why ListLiteralExp does not subclass CollectionLiteralExp at the moment. What I do not understand is why ListLiteralExp defines 'element : OCLExpression' reference instead of 'part : CollectionLiteralPart'. I cannot reuse CollectionRange then for example.

[eclipse-qvt-oml-bot]

By Ed Willink on Dec 09, 2009 16:58

I didn't design ListLiteralExp; I just analyzed it. My initial reaction was the same as yours. But if you consider a list of objects, ListLitetalExp realises it with a list. CollectionLiteralExp, needs an additional CollectionItem for each list element, so there is a significant saving in overhead.

CollectionType.kind added to Bug 297390.

[eclipse-qvt-oml-bot]

By Radomil Dvorak on Dec 09, 2009 17:51

(In reply to comment #8)

I didn't design ListLiteralExp; I just analyzed it. My initial reaction was the same as yours. But if you consider a list of objects, ListLitetalExp realises it with a list. CollectionLiteralExp, needs an additional CollectionItem for each list element, so there is a significant saving in overhead.

CollectionType.kind added to Bug 297390.

Thanks for considering 'CollectionType.kind'!

As for overhead saving, I can't see any significant gain. How many \ elements would be typically used with these literals? By saving couple of objects in AST I should sacrifice consistency with other collection types at\ the concrete syntax level and also in the implementation, where I have to reimplement all that is done in OCL for handling collection literals.

IOW, I can imagine how many people will ask in the newsgroup why they can't make\ List { 1..10 } work, while Bag is fine. Me answering, "we needed to save an overhead somewhere inside QVT" ;).

The use of collection parts is a reasonable level of abstraction, which can facilitate another ways to initialize collections, once invented. Though, so\ far we have just two concrete parts.

Or perhaps, I completely miss something that makes this a clear benefit.

[eclipse-qvt-oml-bot]

By Ed Willink on Dec 10, 2009 00:49

IOW, I can imagine how many people will ask in the newsgroup why they can't make List { 1..10 } work, while Bag is fine.

Or even Sequence.

The use of collection parts is a reasonable level of abstraction, which can facilitate another ways to initialize collections, once invented. Though, so far we have just two concrete parts.

Or perhaps, I completely miss something that makes this a clear benefit.

My QVTo knowledge is very limited. My analysis was just a rationalisation for myself. If you, as a QVTo expert, think ListLiteralExp is damaging then raise an OMG issue quickly to counterbalance the recent introduction. Alternatively start a discussion with Mariano to find out why it's useful.

[eclipse-qvt-oml-bot]

By Radomil Dvorak on Dec 10, 2009 05:04

(In reply to comment #10)

IOW, I can imagine how many people will ask in the newsgroup why they can't make List { 1..10 } work, while Bag is fine.

Or even Sequence.

The use of collection parts is a reasonable level of abstraction, which can facilitate another ways to initialize collections, once invented. Though, so far we have just two concrete parts.

Or perhaps, I completely miss something that makes this a clear benefit.

My QVTo knowledge is very limited. My analysis was just a rationalisation for myself. If you, as a QVTo expert, think ListLiteralExp is damaging then raise an OMG issue quickly to counterbalance the recent introduction. Alternatively start a discussion with Mariano to find out why it's useful.

Unfortunately, after Borland acquisition, our modeling team was terminated, so I was cut off the OMG work and could not participate in the last voting.\ The OMG mailing list is also for members only, but I think I can do what you propose.

From OCL side, it would be reasonable to allow a flexible collection type extensibility, so if #297390 gets fixed, a generic CollectionLiteralExp can be used.