Smalltalk › Frameworks & Tools › Moose

Fame - More flexible opposite definitions

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

3 messages Options

cdelaunay

Fame - More flexible opposite definitions

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
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

Anne Etien

Re: Fame - More flexible opposite definitions

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 <[hidden email]> 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
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

cdelaunay

Re: Fame - More flexible opposite definitions

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 <[hidden email]>:

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 <[hidden email]> 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
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

Cyrille Delaunay

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev