Re: [qvto-dev] Differences between ElementCS and ModelElementCS

[Adolfo Sanchez-Barbudo Herrera <adolfosbh@xxxxxxxxx>]

Hi Ed,

Thanks for the insight.

I'll review the CS metamodels, since I guess that most of the elements 
should be ModelElementCS rather than simple ElementCS.

I agree that I need to get more familiarized with the whole process and 
code. Let's see if debugging test cases helps here.

Then I could properly engineer around the generation framework.

Cheers,
Adolfo.
On 18/07/2013 14:04, Ed Willink wrote:
> Hi
>
> The distinction bettwen ModelElementCS and ElementCS seems clear from
> BaseCST.ecore.
>
> In practice everything is an ElementCS (which might make VisiatbleCS
> redundant, except that separating the interface allows for random third
> party Visitor extension).
>
> A ModelElementCS adds the Pivotable interface, i.e the element has a 1:1
> relation between CS and AS. (It may be slightly more than 1:1 where
> there is CS syntax sugar in which case there as a primary
> 'bidirectioinal' 1<>1 and additional 'unidirectional' 1->1.
>
> If you examine the inheritance of ElementCS you will find that for
> instance MultiplicityCS is not a ModelElementCS since it is just CS
> artefact.
>
> Perhaps similarly PathElementCS and PathNameCS are not ModelElementCS
> even though they implement Pivotable. This could be reviewed; quick test
> just change it and regenerate and see if tests pass. However I see no
> point reviewing today. It should form part of the 'PivotableWeaver' that
> autogenerates the set/resetPivot code.
>
> Similarly the 'ReferredElement' weaver will handle the
> getReferredElement method.
>
> ... for ideally 100% of the manual contributions.
>
> Sadly the elegant QVTo weaving falls foul of PIM/PSM nsURI schizophrenia
> and genmodel limitations so these weavers will all have to go into
> insert.javajet and OCLBuildGenModelUtil (or their extensions).
>
> I very strongly recommend leaving these things as they are until you are
> familiar with the entire problem, then formulate a strategy to
> improve/autogenerate effectively for the entire problem.
>
>      Regards
>
>          Ed Willink
>
> On 18/07/2013 13:03, Adolfo Sanchez-Barbudo Herrera wrote:
> > Hi Ed,
> >
> > While making ImperativeOCL/QVTOperational editors work (error makers
> > free), I realized that my CS elements not only need to be VisitableCS
> > but also ElementCS. It makes sense.
> >
> > While debugging my first failing test case, I've realized that a
> > pivotResource was not properly created because my csResource root
> > element didn't extend ModelElementCS (CS2PivotResourceAdapter, line 107).
> > Which additional semantic provide this ModelElementCS ?, Are there
> > identified situations where this distinction makes sense/is necessary ?.
> >
> > Do you want to review this ElementCS/ModelElementCS distinction
> > usage?. Do you want I do it ?
> >
> > Cheers,
> > Adolfo.
> > _______________________________________________
> > qvto-dev mailing list
> > qvto-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/qvto-dev
> >
> >
> > -----
> > No virus found in this message.
> > Checked by AVG - www.avg.com
> > Version: 2013.0.3349 / Virus Database: 3204/6500 - Release Date: 07/17/13
>
> _______________________________________________
> qvto-dev mailing list
> qvto-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/qvto-dev