6 Apr
2017
6 Apr
'17
11:10 a.m.
Hi Cyril,
As it has already been announced in this list, we (the RMod team and Pavel in particular)
are working on a new definition of Fame and Famix to enable such things. Work are in
progress.
I know that at Synectique, you may have not the same time management. But please don’t add
such pragmas, they will be removed in a couple of months and they will add more mess than
solve issues. Pavel should announce very soon where he is and where he goes.
Because you are not so far away from Pavel, please take a day to come in our office or
invite Pavel. But please do not do things on your side. Synectique is one of the company
that uses the most Moose and Famix it would be sad that you do not get the official one.
Anne
Le 6 avr. 2017 à 09:43, Cyrille Delaunay
<cy.delaunay(a)gmail.com> a écrit :
Hello Moosers,
At synectique, we subclassed some FAMIX classes in order to provide our own specific
behavior and to modelize some language specifities.
In this context, we are facing cases where several properties in the FAMIX hierarchy
point to the same opposite.
Fame complains about that, and raises an error when exporting the mse.
Sometimes, this kind of error helps us to highlight inconsistencies in the implementation
of our meta model,
but some other times, we would like to be more tolerant, and allow a property to define
several "type" classes,
which has for consequence that each of these "type" classes will define the
same opposite.
This cases mainly occur when working around famix single inheritance limits.
A workaround I have thought about is that when defining such a duplicate opposite,
we could inform fame that we don't want this definition to raise a validation error.
For example, adding a pragma such as <alternateOpposite>, that would be considered
by the fame pragma processor when validating the model.
Does this behavior has any interest for moose in general ?
Would you have other suggestions ?
Should we keep this new behavior in our own Pragma processor class ?
If yes, may I factorize the references to MoosePragmaProcessor in the code of moose ?
--
Cyrille Delaunay
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev