15 Apr
2013
15 Apr
'13
11:34 a.m.
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. 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 <anne.etien(a)univ-lille1.fr>wrote;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 :
are Java
specific (isAbstract, isFinal, isPublic, ...), so that a Function,
a Package or a LocalVariable have the isAbstract, isFinal properties and
AnnotationInstances relation.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
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 <anne.etien(a)univ-lille1.fr>wrote;wrote:
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
:-) )
to compose new entities from a set of simple "properties" (not in
Famix sense of property).
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
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.
of having a
method belongs to a class as a relation.
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 neither is AnnotationInstances, …
there it could make sense.
> - Abstract Famix classes like NamedEntity inlude many properties that
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 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 :
are Java
specific (isAbstract, isFinal, isPublic, ...), so that a Function,
a Package or a LocalVariable have the isAbstract, isFinal properties and
AnnotationInstances relation.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow"
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
:-) )
to compose new entities from a set of simple "properties" (not in
Famix sense of property).
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
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.
of having a
method belongs to a class as a relation.
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 neither is AnnotationInstances, …
there it could make sense.
> - Abstract Famix classes like NamedEntity inlude many properties that
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