6 Apr
2017
6 Apr
'17
9:43 a.m.
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
6 Apr
6 Apr
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
11:48 a.m.
Thank you Anne.
Yes I know there is some work in progress around this topic and for sure we
will want to move and benefit from it.
In particular, having modular implementation of the meta model would fix i
think lots of our current limits.
As I said, i am just thinking about a cheap workaround for us in the
meantime.
So ok, I understand that such "new pragmas" do not make sense for Moose
right now :)
2017-04-06 11:10 GMT+02:00 Anne Etien <anne.etien(a)univ-lille1.fr>fr>:
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
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--
Cyrille Delaunay
2817
days inactive
2817
days old
2 comments
2 participants
participants (2)
-
Anne Etien -
Cyrille Delaunay