Re: [mdt-papyrus.dev] Where is the code generator for diagram tests?

["Christian W. Damus" <give.a.damus@xxxxxxxxx>]

Hi, Sergey,

Thanks for the reply.  I tried ensuring a consistent ordering of the elements being added to the Package::packagedElement collection, but I found that it didn’t make a difference.  I think it’s because the value of packagedElement is represented internally as an unordered set (before it is put back into the model’s EList implementation), so adding elements from an ordered collection makes no difference (they become unordered by being added to the set).

Or perhaps I missed a case in my own machinations …

Besides that the the only orderedBy(…) that I can reasonably do is by name, which doesn’t reflect the ordering in the source model, which is what I’m really aiming for and which I can’t get natively with OCL/QVTo (which is fine).  As I mentioned already, I can use Java blackboxes for all read and write access to these unordered collections, but then that degrades the transformation’s readability.

Cheers,

Christian

On Wed, Apr 15, 2015 at 12:16 PM, Sergey Boyko <serg.boyko2011@xxxxxxxxx> wrote:

Hi Christian,

For multivalued features that are inherently unordered (like Package::packagedElement in UML.ecore) Ed W. suggested to use  ->sortedBy(...)  function.  For example packaged elements can be sorted by names.

Surely not every access to packagedElement should be sorted but only the result collections that are stored to intermediate model(s).

Regards,

  Sergey Boyko.

On Wed, Apr 15, 2015 at 3:46 PM, Christian W. Damus <give.a.damus@xxxxxxxxx> wrote:

Hi, Juan,

Thanks for your feed-back.  I’m glad to hear it, especially since it seems to align so well with my own inclinations.  :-)

I don’t think there was a problem with the ordering of the features of classifiers.  The main problem stems from Package::packagedElement, which is (understandably) unordered.  The intermediate models in this transformation pipeline make heavy use of packaged elements:  the test-context classes, of course, but more importantly the InstanceSpecifications in the UML representation of the GMFGen are all randomly ordered.

Cheers,

Christian