ideas for a new Famix

Hi guys,

Food for thoughts.
It's a long one, but it is literally the result of years of thinking and discussing Famix in our group.
This is still work in progress so that those who might want to participate have a chance to do it before everything is already decided.

You can call it a vision for the next Famix (and Fame incidentally)


Although the goal of Famix is to be able to model systems in any language, the reality of it is that it focuses very much on OO, and more precisely on ST and Java.
And even with only these two languages, it is already difficult.
Famix is the union of ST + Java which means unneeded complexity when you deal with only one of the two.

Same happen when considering something outside the current scope.
For example something as a C function calling another C function is currently represented as an invocation, which means it has a receiver (the object on which a message is sent, useless in C) and also a collection of candidates (whereas in C function names must be unique).

When working with different languages, mostly not OO, it started to annoy me, and I wanted to see how we could redesign a new Famix so that:
- we have a bare core metamodel that is really language independent
- something that is easily extensible so that one does not have to redefine basic stuff (what is a variable, a class, a method)
- no "hidden" associations as the declaredType of a FamixStructuralEntity
- it is completely model driven, which means we can regenerate all the code in Smalltalk, Java and other languages from the metamodel. Having Fame (and thus Famix) in Java helped a lot when I did VerveineJ. I can imagine having a C implementation of Fame could be nice to reuse old parsers based on Bison+Flex :-)

I had two other requirements steming from the way I see metamodels: primarily as conceptual representations of some domain. They should be as clear as possible about what is meant by the concepts and their relationships, and also it should be as close as possible from the human conception of the domain.
This implies:
- I want it to be typed. C and Java have types to guard the developer from making mistakes, I want types to clarify the meaning of the concepts, like defining an ontology
- I want it to have multiple inheritance, with as little restrictions as possible (typical multiple inheritance problems in programming languages) to try to be closer from the abstract conception of the domain.

In short, we are looking for the Graal, nothing new here :-)
Now the question is how far we can push it and how close can we get?

Discussing we had the idea of a GenericEntity, probably equivalent to the current FamixSourcedEntity.
We could have generic FunctionEntity, VariableEntity, ClassEntity inheriting from GenericEntity; MethodEntity inheriting from FunctionEntity.
And all these only stating consensual things like a class defines methods, a function defines variables.

Independent of that (meant to be used through multiple inheritance) we would have the idea that there are ContainerEntity, BehavioredEntity, TypedEntity, maybe even NamedEntity.
So that FunctionEntity (which is a GenericEntity) would also be a BehavioredEntity + a NamedEntity.

Invocation would occur between two BehavioredEntity

And we could create new entities by combining all these things.
For example, a JavaMethodEntity would inherit from MethodEntity + TypedEntity + ContainerEntity (may define classes)
A PascalProgram could be a GenericEntity+ContainerEntity (contains functions)+BehavioredEntity


All this would be declarative in the new Famix and translated in some way by Fame into different languages (lets concentrate on Pharo and Java for now).
In a first step, behaviour to be reused (like navigation between a ContainerEntity and its members) could be stored directly in the metamodel for each target language and then copied appropriately when generating actual code.
In a second step I also dream of using FAST (AST metamodeling, see http://youtu.be/dRr3WHOD3x4) to model the behaviour abstractly and then generate the code from that.


I believe this would introduce only two real changes to Moose: First Fame would have to allow for multiple inheritance, second MooseChef would have to be re-designed to allow for new queries (at least ContainerEntity, BehavioredEntity).
And of course, we would need to using it concretely to see whether it really helps considering new languages


So this is about it.
If you have any idea or comment on this, we will be glad to here from you.
If you want to participate, we will be even gladder because we are not that many and it is a lot of work.

nicolas

--
Nicolas Anquetil -- RMod research team (Inria)

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

Doru, there is something in your mail configuration that is breaking the mail threads :)

On Apr 10, 2013, at 8:57 AM, Tudor Girba <[hidden email]> wrote:

Hi,

On Wed, Apr 10, 2013 at 8:36 AM, Nicolas Anquetil <[hidden email]> wrote:

thank you for you contribution.

I had a similar discussion with Damien Cassou (about traits).

First, it depends a lot on what you call a Trait.

Trait has only one meaning in programming languages, and it denotes a mechanism for reuse. Multiple inheritance is also a mechanism for reuse. The difference lies in the semantics of specifying and handling the reuse.

 

What I understood is that traits boil down to an inheritance mechanism where you can specify how each property is inherited.
Typically, you don't specify anything ("normal inheritance") but when you multiply inherit the same property from two super-class, you can rename one of the 2 property (aliasing) or reject it (restriction).

So from this point of view, yes we will use Traits because we also need to deal with name collision in multiple inheritance.

Second we want to have attributes in the Famix concepts.
Again, as I understand, in Pharo, traits are currently stateless due to compilation/optimization issue.
But Fame and Famix or not real programming languages. They need to be compiled to a programming language which is compiled to a low level language.
Because the first "compilation" goes to a language with symbols (instead of accessing attributes by their position), there does not seem to be any difficulty in considering "statefull traits" in Fame/Famix.
Both methods and attributes would be treated the same (inheritance + possible aliasing/restriction)

So in this sense, we can say that we will be using statefull traits.

Yes. And the way we can get around the current Pharo Trait implementation is by using state dictionary, like we are doing now in MooseEntity.

 

But in the end, I am not too sure whether it makes sense to speak of Traits at this level of abstraction.

It does.

 

We are currently aiming at multiple inheritance of both attributes+methods with the aliasing/restriction mechanisms.
Is this traits?

No. we are aiming at composing meta-models and for that we need a language mechanism. Hence, talking about the mechanism makes perfect sense. And we will use Traits because it is the best on the market.

 

As for compiling Famix to programming languages, this is a very different story.
Currently the way it works is that we program things in Pharo, add the appropriate pragmas to the Pharo methods, and then generate Famix from the Pharo classes.
What I would like to have is more top-down: we generate everything in Famix (will need a bit of tooling here), and then we generate Pharo code automatically.

Done that way, the discussion about trait and inheritance can be eliminated because actually, one can generate a flat set of Pharo classes where all inheritance has been inlined.
In some sense, it is again similar to current implementation of Traits in Pharo where the Traits methods are compiled inside the Pharo class.

So again it will be kind of using traits again.

I disagree. We keep a 1-to-1 mapping to Pharo. This is critical because we are using Pharo as the execution language and we do not want to deal with two model abstractions. Of course, we should also build tools, such as the MetaBrowser that make it easier for us to handle the meta-descriptions, but in the end we want to keep a clear mapping to Pharo code. This will save us a ton of trouble down the road.

Given that Traits are already supported in the execution language (Pharo), we can directly use this 1-to-1 mapping without any problems. So, we will not rely on generation at all. The same as it is now. And we put in place tests that check the meta-descriptions.

Generation only looks cheap, but as soon as you want to manipulate anything at the lower level, it becomes highly expensive. We managed to keep away from this and it payed off until now. I insist on this point :).

 

 

As for Alain's work.
I have it on my disk, but did not have the time to look at it yet.

I think we should start from this one and see how we can support Fame-Traits in Java.

Doru

 

nicolas

On 04/09/2013 12:11 PM, Tudor Girba wrote:

Hi,

Thanks for taking the time to lay this out. I am certainly interested in participating. I agree with most of it, except one thing: multiple inheritance.

As I said before, we should use Traits instead. There are only benefits from using Traits:

- Traits are already supported by Pharo, making it easy to integrate meta-descriptions with existing code due to the 1-to-1 mapping between meta-descriptions and code, and thus benefits from tooling.

- Traits are better at dealing with conflicts.

- Java anyway does not have multiple inheritance, so choosing between Traits and multiple inheritance has a similar impact.

- Traits can be used as types as well.

- Chef showed that we can nicely use Traits for navigation.

- And we already have a first version of a Traits extension to Fame (built by Alain Plantec).

Cheers,

Doru

On Tue, Apr 9, 2013 at 11:44 AM, Nicolas Anquetil <[hidden email]> wrote:

Hi guys,

Food for thoughts.
It's a long one, but it is literally the result of years of thinking and discussing Famix in our group.
This is still work in progress so that those who might want to participate have a chance to do it before everything is already decided.

You can call it a vision for the next Famix (and Fame incidentally)


Although the goal of Famix is to be able to model systems in any language, the reality of it is that it focuses very much on OO, and more precisely on ST and Java.
And even with only these two languages, it is already difficult.
Famix is the union of ST + Java which means unneeded complexity when you deal with only one of the two.

Same happen when considering something outside the current scope.
For example something as a C function calling another C function is currently represented as an invocation, which means it has a receiver (the object on which a message is sent, useless in C) and also a collection of candidates (whereas in C function names must be unique).

When working with different languages, mostly not OO, it started to annoy me, and I wanted to see how we could redesign a new Famix so that:
- we have a bare core metamodel that is really language independent
- something that is easily extensible so that one does not have to redefine basic stuff (what is a variable, a class, a method)
- no "hidden" associations as the declaredType of a FamixStructuralEntity
- it is completely model driven, which means we can regenerate all the code in Smalltalk, Java and other languages from the metamodel. Having Fame (and thus Famix) in Java helped a lot when I did VerveineJ. I can imagine having a C implementation of Fame could be nice to reuse old parsers based on Bison+Flex :-)

I had two other requirements steming from the way I see metamodels: primarily as conceptual representations of some domain. They should be as clear as possible about what is meant by the concepts and their relationships, and also it should be as close as possible from the human conception of the domain.
This implies:
- I want it to be typed. C and Java have types to guard the developer from making mistakes, I want types to clarify the meaning of the concepts, like defining an ontology
- I want it to have multiple inheritance, with as little restrictions as possible (typical multiple inheritance problems in programming languages) to try to be closer from the abstract conception of the domain.

In short, we are looking for the Graal, nothing new here :-)
Now the question is how far we can push it and how close can we get?

Discussing we had the idea of a GenericEntity, probably equivalent to the current FamixSourcedEntity.
We could have generic FunctionEntity, VariableEntity, ClassEntity inheriting from GenericEntity; MethodEntity inheriting from FunctionEntity.
And all these only stating consensual things like a class defines methods, a function defines variables.

Independent of that (meant to be used through multiple inheritance) we would have the idea that there are ContainerEntity, BehavioredEntity, TypedEntity, maybe even NamedEntity.
So that FunctionEntity (which is a GenericEntity) would also be a BehavioredEntity + a NamedEntity.

Invocation would occur between two BehavioredEntity

And we could create new entities by combining all these things.
For example, a JavaMethodEntity would inherit from MethodEntity + TypedEntity + ContainerEntity (may define classes)
A PascalProgram could be a GenericEntity+ContainerEntity (contains functions)+BehavioredEntity


All this would be declarative in the new Famix and translated in some way by Fame into different languages (lets concentrate on Pharo and Java for now).
In a first step, behaviour to be reused (like navigation between a ContainerEntity and its members) could be stored directly in the metamodel for each target language and then copied appropriately when generating actual code.
In a second step I also dream of using FAST (AST metamodeling, see http://youtu.be/dRr3WHOD3x4) to model the behaviour abstractly and then generate the code from that.


I believe this would introduce only two real changes to Moose: First Fame would have to allow for multiple inheritance, second MooseChef would have to be re-designed to allow for new queries (at least ContainerEntity, BehavioredEntity).
And of course, we would need to using it concretely to see whether it really helps considering new languages


So this is about it.
If you have any idea or comment on this, we will be glad to here from you.
If you want to participate, we will be even gladder because we are not that many and it is a lot of work.

nicolas

--
Nicolas Anquetil -- RMod research team (Inria)

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

--

www.tudorgirba.com

"Every thing has its own flow"

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

-- 
Nicolas Anquetil -- RMod research team (Inria)

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

--

www.tudorgirba.com

"Every thing has its own flow"

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

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

Hi,

Sorry for arriving after the battle.

I just want to talk about my experiment in metamodel and model generation.

It is clear for me that the concept of Trait should not appear in Fame. It can be use in its implementation, but can't be considered at the same level than Element, Class, Property or Package.

I fully agree with Nicolas, when he says that Doru is talking programming and he is talking metamodelling.

So Fame is a metametamodel. What is the concept that we want to implement with Traits (or something else) that does not exist currently in Fame? This concept is reuse. A class can reuse several properties from another or several other classes. Sometimes, we want to specify that the property is not reuse as such but using alias...

There exist different way to implement this thing. Smalltalk calls it Traits, Eiffel calls it inheritance (there exist perhaps other). There are certainly some differences that are yet too subtle for me.
Moreover, methods do not appear in Fame so according to me Traits should neither not appear. But it may happen that I do not understand how it should be introduced.

Considering the generation. It is currently performed a lot. It makes sense only if we don't touch the intermediary nor the final level, otherwise the high level and the low level are no more align.

I hope it can help in the discussion.
Anne

Le 13 avr. 2013 à 09:08, stephane ducasse a écrit :

>
> On Apr 12, 2013, at 1:32 PM, Nicolas Anquetil <[hidden email]> wrote:
>
>>
>> On 04/11/2013 09:04 AM, stephane ducasse wrote:
>>> Nicolas
>>>
>>> I would really like if you could (with camille/anne/damien/usman) have a document (can a couple of slide)
>>> where you precisely shows the problem synectiquers encountered with FAMIX.
>>> It will help for the solution/paper :)
>>> And it will help me to understand what are the key problems.
>>>
>>> Stef
>>
>> Some problems we see with current Famix.
>> Several of them just say that entities have too many properties that do not make sense for them.
>       give example
>
>> Other could be solved by adding more properties to generic entities.
>       but usless for others :).
>
>
>
>> This is what prompted us to think about multiple inheritance (or traits :-) ) to compose new entities from a set of simple "properties" (not in Famix sense of property).
>
>       traits-based :)
>       indeed traits should be good for that.
>       Probably what you want is to have pair of traits that you apply to both end of a relation also.
>
>
>> - Invocation is designed for OO. There is no receiver in procedural languages. This is a semantical problem, but practical too as 'printOn:' has to be redefined to show 'from -> to' instead of 'from -> receiver'
>
>       but we could have a superclass for call and a subclass for invocation?
>
>> - Invocation is designed for "non-typed language". In statically typed languages or procedural languages one knows (or has a pretty good idea) the function/method called. In these cases, 'candidates' adds unnecessary complexity
>
>       Really? In Java there are cases where you do not know. For example if you have an interface: you may have different classes?
>
>
>> - Some relations between entities are reified (Associations) other not. E.g. Access is an association, but the type of a variable is a "simple" relation.
>       this is the question of what is your domain and if you have to attach information to the relation.
>       To me I do not see why I would like a relation for type.
>
>> BelongsTo is not reified,
>       Why do you want to have pointers as relations?
>       To me it will blow up metamodels for not. I do not see the value of having a method belongs to a class as a relation.
>
>> neither is AnnotationInstances, …
>
>       there it could make sense.
>
>> - Abstract Famix classes like NamedEntity inlude many properties that are Java specific (isAbstract, isFinal, isPublic, ...), so that a Function, a Package or a LocalVariable have the isAbstract, isFinal properties and AnnotationInstances relation.
>
>       Yes the tyranny of the dominant decomposition but now do you want to have to express everywhere where
>
>>
>> - This is further complicated by the fact that these properties are derived from 'modifiers'. So when looking at the meta-description of NamedEntites, one sees many redundant properties.
>
>       yes probably should be rethought
>
>> - A language like Cobol has no functions, it has paragraph that is a sequence of statement with a label to go to it and a return statement (with no value) at the end. For them 'signature' and 'parameters' are meaningless.
>
>       so you will have a hard job to always compose a new model for each language if you do not accept some interpretation.
>       It also means that you will have hard time to reuse tools.
>
>> - 'functions' are defined for ScopingEntity which is not a BehaviouralEntity. But there are cases where we want both (a Pascal program would be an example)
>       this is a nice one :)
>
>> - all sourcedEntities have a sourceAnchor and comments, which does not make sense for ScopingEntities, or ImplicitVariables
>>
>> - for synectique we want an alternative notion of container where a container only contains BehaviouralEntity, not other entities (a Smalltalk method would not be a container).
>
>       so it would be interesting to start identifying the traits you want to have a build a libraries.
>
>>
>> nicolas
>>
>> --
>> Nicolas Anquetil -- RMod research team (Inria)
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev


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

On Apr 16, 2013, at 7:08 AM, Tudor Girba <[hidden email]> wrote:

> Hi Stef,
>
> Nicolas and Anne argued that generation is used all the time, for example when compiling. So, I agreed that we use it like that only that we do not want to see it :).

Yes but we do not want to compile smalltalk code from Fame :)

>
> Doru
>
> On Apr 15, 2013, at 11:11 PM, stephane ducasse <[hidden email]> wrote:
>
>>
>> On Apr 15, 2013, at 11:34 AM, Tudor Girba <[hidden email]> wrote:
>>
>>> Hi Nicolas, hi Anne,
>>>
>>> I agree with the distinction of implementation reuse and sub-typing. When I said reuse, I did not refer to implementation reuse, but to typing reuse.
>>>
>>> When you say "Famix as implementation language", I presume you mean "the structure of FAMIX as implementation language". As soon as you will talk about "FAMIX as executable language" you will run into the little problem of having an executable language in the first place. In Moose, we want to have Smalltalk as the executable language. This is not just a matter of implementation. It is an important meta-modeling aspect.
>>>
>>> Fame is indeed a meta-meta-model, but Traits should be captured there as well. Obviously not the Smalltalk Traits, but the Fame Traits. As I said before, the important part of the reuse mechanism resides in its ability to deal with conflicts. Multiple-inheritance in its known language incarnations (e.g., C++) is a mechanism that comes with ambiguities. That is why I do not like this term. Traits comes with an explicit conflict resolution mechanism. That is why I like this one and I would like to see this mechanism in Fame.
>>>
>>> The most important part for me is that when we will come down from the paper discussion into the programming trenches, the mapping to the underlying implementation is decisive. Take PetitParser, for example. It also has a meta-model, but it also come with a neat mapping to Smalltalk classes. This helps us develop and debug with Smalltalk tools. Of course, if we get a dedicated tool, we can do even more cool things, like we do in the PPBrowser.
>>>
>>> As for generation, I completely agree that we are doing it all the time, but it only works when we do not get to see it.
>> I do not get it. Do we generate?
>>
>>
>>> But, we get to see FAMIX all the time, and as a consequence, FAMIX should be editable at plain Smalltalk level. Doing it otherwise would be shooting ourselves in the foot. So, I do not want to rely on generation in the Smalltalk incarnation of FAMIX.
>>>
>>> Anyway, it seems we are making progress and I think we are actually not disagreeing, only picking up on names. I think this is a really exciting direction that was long on the roadmap, but never really tackled.
>>>
>>> Cheers,
>>> Doru
>>>
>>>
>>>
>>> On Mon, Apr 15, 2013 at 11:12 AM, Anne Etien <[hidden email]> wrote:
>>> Hi,
>>>
>>> Sorry for arriving after the battle.
>>>
>>> I just want to talk about my experiment in metamodel and model generation.
>>>
>>> It is clear for me that the concept of Trait should not appear in Fame. It can be use in its implementation, but can't be considered at the same level than Element, Class, Property or Package.
>>>
>>> I fully agree with Nicolas, when he says that Doru is talking programming and he is talking metamodelling.
>>>
>>> So Fame is a metametamodel. What is the concept that we want to implement with Traits (or something else) that does not exist currently in Fame? This concept is reuse. A class can reuse several properties from another or several other classes. Sometimes, we want to specify that the property is not reuse as such but using alias...
>>>
>>> There exist different way to implement this thing. Smalltalk calls it Traits, Eiffel calls it inheritance (there exist perhaps other). There are certainly some differences that are yet too subtle for me.
>>> Moreover, methods do not appear in Fame so according to me Traits should neither not appear. But it may happen that I do not understand how it should be introduced.
>>>
>>> Considering the generation. It is currently performed a lot. It makes sense only if we don't touch the intermediary nor the final level, otherwise the high level and the low level are no more align.
>>>
>>> I hope it can help in the discussion.
>>> Anne
>>>
>>> Le 13 avr. 2013 à 09:08, stephane ducasse a écrit :
>>>
>>>>
>>>> On Apr 12, 2013, at 1:32 PM, Nicolas Anquetil <[hidden email]> wrote:
>>>>
>>>>>
>>>>> On 04/11/2013 09:04 AM, stephane ducasse wrote:
>>>>>> Nicolas
>>>>>>
>>>>>> I would really like if you could (with camille/anne/damien/usman) have a document (can a couple of slide)
>>>>>> where you precisely shows the problem synectiquers encountered with FAMIX.
>>>>>> It will help for the solution/paper :)
>>>>>> And it will help me to understand what are the key problems.
>>>>>>
>>>>>> Stef
>>>>>
>>>>> Some problems we see with current Famix.
>>>>> Several of them just say that entities have too many properties that do not make sense for them.
>>>>      give example
>>>>
>>>>> Other could be solved by adding more properties to generic entities.
>>>>      but usless for others :).
>>>>
>>>>
>>>>
>>>>> This is what prompted us to think about multiple inheritance (or traits :-) ) to compose new entities from a set of simple "properties" (not in Famix sense of property).
>>>>
>>>>      traits-based :)
>>>>      indeed traits should be good for that.
>>>>      Probably what you want is to have pair of traits that you apply to both end of a relation also.
>>>>
>>>>
>>>>> - Invocation is designed for OO. There is no receiver in procedural languages. This is a semantical problem, but practical too as 'printOn:' has to be redefined to show 'from -> to' instead of 'from -> receiver'
>>>>
>>>>      but we could have a superclass for call and a subclass for invocation?
>>>>
>>>>> - Invocation is designed for "non-typed language". In statically typed languages or procedural languages one knows (or has a pretty good idea) the function/method called. In these cases, 'candidates' adds unnecessary complexity
>>>>
>>>>      Really? In Java there are cases where you do not know. For example if you have an interface: you may have different classes?
>>>>
>>>>
>>>>> - Some relations between entities are reified (Associations) other not. E.g. Access is an association, but the type of a variable is a "simple" relation.
>>>>      this is the question of what is your domain and if you have to attach information to the relation.
>>>>      To me I do not see why I would like a relation for type.
>>>>
>>>>> BelongsTo is not reified,
>>>>      Why do you want to have pointers as relations?
>>>>      To me it will blow up metamodels for not. I do not see the value of having a method belongs to a class as a relation.
>>>>
>>>>> neither is AnnotationInstances, …
>>>>
>>>>      there it could make sense.
>>>>
>>>>> - Abstract Famix classes like NamedEntity inlude many properties that are Java specific (isAbstract, isFinal, isPublic, ...), so that a Function, a Package or a LocalVariable have the isAbstract, isFinal properties and AnnotationInstances relation.
>>>>
>>>>      Yes the tyranny of the dominant decomposition but now do you want to have to express everywhere where
>>>>
>>>>>
>>>>> - This is further complicated by the fact that these properties are derived from 'modifiers'. So when looking at the meta-description of NamedEntites, one sees many redundant properties.
>>>>
>>>>      yes probably should be rethought
>>>>
>>>>> - A language like Cobol has no functions, it has paragraph that is a sequence of statement with a label to go to it and a return statement (with no value) at the end. For them 'signature' and 'parameters' are meaningless.
>>>>
>>>>      so you will have a hard job to always compose a new model for each language if you do not accept some interpretation.
>>>>      It also means that you will have hard time to reuse tools.
>>>>
>>>>> - 'functions' are defined for ScopingEntity which is not a BehaviouralEntity. But there are cases where we want both (a Pascal program would be an example)
>>>>      this is a nice one :)
>>>>
>>>>> - all sourcedEntities have a sourceAnchor and comments, which does not make sense for ScopingEntities, or ImplicitVariables
>>>>>
>>>>> - for synectique we want an alternative notion of container where a container only contains BehaviouralEntity, not other entities (a Smalltalk method would not be a container).
>>>>
>>>>      so it would be interesting to start identifying the traits you want to have a build a libraries.
>>>>
>>>>>
>>>>> nicolas
>>>>>
>>>>> --
>>>>> Nicolas Anquetil -- RMod research team (Inria)
>>>>> _______________________________________________
>>>>> Moose-dev mailing list
>>>>> [hidden email]
>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> [hidden email]
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>>
>>>
>>> --
>>> www.tudorgirba.com
>>>
>>> "Every thing has its own flow"
>>>
>>>
>>> On Mon, Apr 15, 2013 at 11:12 AM, Anne Etien <[hidden email]> wrote:
>>> Hi,
>>>
>>> Sorry for arriving after the battle.
>>>
>>> I just want to talk about my experiment in metamodel and model generation.
>>>
>>> It is clear for me that the concept of Trait should not appear in Fame. It can be use in its implementation, but can't be considered at the same level than Element, Class, Property or Package.
>>>
>>> I fully agree with Nicolas, when he says that Doru is talking programming and he is talking metamodelling.
>>>
>>> So Fame is a metametamodel. What is the concept that we want to implement with Traits (or something else) that does not exist currently in Fame? This concept is reuse. A class can reuse several properties from another or several other classes. Sometimes, we want to specify that the property is not reuse as such but using alias...
>>>
>>> There exist different way to implement this thing. Smalltalk calls it Traits, Eiffel calls it inheritance (there exist perhaps other). There are certainly some differences that are yet too subtle for me.
>>> Moreover, methods do not appear in Fame so according to me Traits should neither not appear. But it may happen that I do not understand how it should be introduced.
>>>
>>> Considering the generation. It is currently performed a lot. It makes sense only if we don't touch the intermediary nor the final level, otherwise the high level and the low level are no more align.
>>>
>>> I hope it can help in the discussion.
>>> Anne
>>>
>>> Le 13 avr. 2013 à 09:08, stephane ducasse a écrit :
>>>
>>>>
>>>> On Apr 12, 2013, at 1:32 PM, Nicolas Anquetil <[hidden email]> wrote:
>>>>
>>>>>
>>>>> On 04/11/2013 09:04 AM, stephane ducasse wrote:
>>>>>> Nicolas
>>>>>>
>>>>>> I would really like if you could (with camille/anne/damien/usman) have a document (can a couple of slide)
>>>>>> where you precisely shows the problem synectiquers encountered with FAMIX.
>>>>>> It will help for the solution/paper :)
>>>>>> And it will help me to understand what are the key problems.
>>>>>>
>>>>>> Stef
>>>>>
>>>>> Some problems we see with current Famix.
>>>>> Several of them just say that entities have too many properties that do not make sense for them.
>>>>      give example
>>>>
>>>>> Other could be solved by adding more properties to generic entities.
>>>>      but usless for others :).
>>>>
>>>>
>>>>
>>>>> This is what prompted us to think about multiple inheritance (or traits :-) ) to compose new entities from a set of simple "properties" (not in Famix sense of property).
>>>>
>>>>      traits-based :)
>>>>      indeed traits should be good for that.
>>>>      Probably what you want is to have pair of traits that you apply to both end of a relation also.
>>>>
>>>>
>>>>> - Invocation is designed for OO. There is no receiver in procedural languages. This is a semantical problem, but practical too as 'printOn:' has to be redefined to show 'from -> to' instead of 'from -> receiver'
>>>>
>>>>      but we could have a superclass for call and a subclass for invocation?
>>>>
>>>>> - Invocation is designed for "non-typed language". In statically typed languages or procedural languages one knows (or has a pretty good idea) the function/method called. In these cases, 'candidates' adds unnecessary complexity
>>>>
>>>>      Really? In Java there are cases where you do not know. For example if you have an interface: you may have different classes?
>>>>
>>>>
>>>>> - Some relations between entities are reified (Associations) other not. E.g. Access is an association, but the type of a variable is a "simple" relation.
>>>>      this is the question of what is your domain and if you have to attach information to the relation.
>>>>      To me I do not see why I would like a relation for type.
>>>>
>>>>> BelongsTo is not reified,
>>>>      Why do you want to have pointers as relations?
>>>>      To me it will blow up metamodels for not. I do not see the value of having a method belongs to a class as a relation.
>>>>
>>>>> neither is AnnotationInstances, …
>>>>
>>>>      there it could make sense.
>>>>
>>>>> - Abstract Famix classes like NamedEntity inlude many properties that are Java specific (isAbstract, isFinal, isPublic, ...), so that a Function, a Package or a LocalVariable have the isAbstract, isFinal properties and AnnotationInstances relation.
>>>>
>>>>      Yes the tyranny of the dominant decomposition but now do you want to have to express everywhere where
>>>>
>>>>>
>>>>> - This is further complicated by the fact that these properties are derived from 'modifiers'. So when looking at the meta-description of NamedEntites, one sees many redundant properties.
>>>>
>>>>      yes probably should be rethought
>>>>
>>>>> - A language like Cobol has no functions, it has paragraph that is a sequence of statement with a label to go to it and a return statement (with no value) at the end. For them 'signature' and 'parameters' are meaningless.
>>>>
>>>>      so you will have a hard job to always compose a new model for each language if you do not accept some interpretation.
>>>>      It also means that you will have hard time to reuse tools.
>>>>
>>>>> - 'functions' are defined for ScopingEntity which is not a BehaviouralEntity. But there are cases where we want both (a Pascal program would be an example)
>>>>      this is a nice one :)
>>>>
>>>>> - all sourcedEntities have a sourceAnchor and comments, which does not make sense for ScopingEntities, or ImplicitVariables
>>>>>
>>>>> - for synectique we want an alternative notion of container where a container only contains BehaviouralEntity, not other entities (a Smalltalk method would not be a container).
>>>>
>>>>      so it would be interesting to start identifying the traits you want to have a build a libraries.
>>>>
>>>>>
>>>>> nicolas
>>>>>
>>>>> --
>>>>> Nicolas Anquetil -- RMod research team (Inria)
>>>>> _______________________________________________
>>>>> Moose-dev mailing list
>>>>> [hidden email]
>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> [hidden email]
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>>
>>>
>>> --
>>> www.tudorgirba.com
>>>
>>> "Every thing has its own flow"
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> www.tudorgirba.com
>
> "Problem solving efficiency grows with the abstractness level of problem understanding."
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev


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