16 Apr
2013
16 Apr
'13
7:31 p.m.
On Apr 16, 2013, at 4:15 PM, Nicolas Anquetil <Nicolas.Anquetil(a)inria.fr> wrote:
Hi,
So about traits, we agreed with Doru that we probably are all talking about the same
thing with different names.
I want multiple inheritance in Fame in the sense that I want to be able to say that a
JavaMethod is an Entity + a BehaviouredEntity + TypedEntity + a ContainerEntity
Conflicts needs to be resolved ans traits are the best solution, we agree, but I am
reluctant to call it trait because it seems like a strong reference to Pharo's
traits.
Anyway, let's call it traits as long as we agree that they don't suffer from
Pharo traits limitations
But why don't you define a Smalltalk-level
FameTraits should be "statefull traits" (unlike PharoTraits) because Famix
primarily defines structure.
I don't like Alain's proposal (sorry Alain) because it introduces a new concept
in the metametamodel where I don't think it is needed.
About Fame (or any metametamodel) Damien talks about boxes and links, and it seems an
appropriate level of abstraction. I don't like the idea of having to say Fame has
blue boxes with "normal inheritance" and green boxes with "trait
inheritance".
The immediate solution could be:
- Fame has only one kind of boxes and all inheritance allows for aliasing and restriction
of the inherited properties ("traits inheritance" therefore)
Frankly I do not understand what are the problems.
Because I would just define traits at the Smalltalk level
for BehavioredEntity, TypedEntity…..
and I would describe that with Fame
and see if it working because I have the impression that this is.
The problem is how does this map to a Pharo
implementation?
Because Pharo Traits are stateless and Pharo classes don't have "trait
inheritance"
But in Pharo traits you simply define accessors and in the composite class you define the
instance variables
and you are done.
I don't know right now especially if we insist on
having 1-to-1 mapping between a Pharo class and a Famix box.
But let's try not to limit our solution to what we can implement (as much as we can)
The idea of having code generation was exactly to avoid this problem.
Even if I don't know how to do it nicely for now.
As for another question of steph: why would we
represent things like the type of a variable as an association, it is because it would
allow to build mooseChef queries directly on this.
Ah. Ok
But may be moose chef can be abstracted so that one query returns the same object and you
"simulate" a relation.
This way we can have either relation or attributes-based relationship navigated the same
way and this is decoupled
from the implementation storage.
Because from a space point of view we should pay attention.
What do you think about that?
nicolas
On 04/15/2013 11:09 PM, stephane ducasse wrote:
On Apr 15, 2013, at 11:12 AM, Anne Etien
<anne.etien(a)univ-lille1.fr> wrote:
--
Nicolas Anquetil -- RMod research team (Inria)
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
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.
Why?
I fully agree with Nicolas, when he says that
Doru is talking programming and he is talking metamodelling.
I do not see why this
is an important difference.
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 :
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev On Apr 12, 2013, at 1:32 PM, Nicolas Anquetil
<Nicolas.Anquetil(a)inria.fr> 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
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev