9 Apr
2013
9 Apr
'13
11:44 a.m.
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)
9 Apr
9 Apr
12:11 p.m.
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 <Nicolas.Anquetil(a)inria.fr
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
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/**mailman/listinfo/moose-dev<https://www.iam.un…
--
www.tudorgirba.com
"Every thing has its own flow"
10 Apr
10 Apr
8:36 a.m.
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.
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.
But in the end, I am not too sure whether it makes sense to speak of
Traits at this level of abstraction.
We are currently aiming at multiple inheritance of both
attributes+methods with the aliasing/restriction mechanisms.
Is this traits?
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.
As for Alain's work.
I have it on my disk, but did not have the time to look at it yet.
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
<Nicolas.Anquetil(a)inria.fr <mailto:Nicolas.Anquetil@inria.fr>> 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
Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com <http://www.tudorgirba.com>
"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Nicolas Anquetil -- RMod research team (Inria)
8:57 a.m.
Hi,
On Wed, Apr 10, 2013 at 8:36 AM, Nicolas Anquetil <Nicolas.Anquetil(a)inria.fr
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 <
> Nicolas.Anquetil(a)inria.fr >
>> 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
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> www.tudorgirba.com
> "Every thing has its own flow"
> _______________________________________________
> Moose-dev mailing
listMoose-dev@iam.unibe.chhttps://www.iam.unibe.ch/mailman/listinfo/moose-dev
> --
> 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
--
www.tudorgirba.com
"Every thing has its own flow"
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.
wrote:
10:54 a.m.
New subject: OFFTOPIC Re: Re: ideas for a new Famix
Doru, there is something in your mail configuration that is breaking the mail threads :)
On Apr 10, 2013, at 8:57 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
Hi,
On Wed, Apr 10, 2013 at 8:36 AM, Nicolas Anquetil <Nicolas.Anquetil(a)inria.fr>
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 <Nicolas.Anquetil(a)inria.fr>
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
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
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
--
www.tudorgirba.com
"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
10:58 a.m.
New subject: OFFTOPIC Re: Re: ideas for a new Famix
:( I really do not know what that is. I am using the GMail interface online.
Doru
On Wed, Apr 10, 2013 at 10:54 AM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote;wrote:
Doru, there is something in your mail configuration
that is breaking the
mail threads :)
On Apr 10, 2013, at 8:57 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
Hi,
On Wed, Apr 10, 2013 at 8:36 AM, Nicolas Anquetil <
Nicolas.Anquetil(a)inria.fr> wrote:
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 <
> Nicolas.Anquetil(a)inria.fr> 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
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> www.tudorgirba.com
> "Every thing has its own
flow"
> _______________________________________________
> Moose-dev mailing
listMoose-dev@iam.unibe.chhttps://www.iam.unibe.ch/mailman/listinfo/moose-dev
> --
> 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
--
www.tudorgirba.com
"Every thing has its own flow"
_______________________________________________
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
--
www.tudorgirba.com
"Every thing has its own flow"
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.
12 Apr
12 Apr
11:52 a.m.
On 04/10/2013 08:57 AM, Tudor Girba wrote:
Hi,
On Wed, Apr 10, 2013 at 8:36 AM, Nicolas Anquetil
<Nicolas.Anquetil(a)inria.fr <mailto:Nicolas.Anquetil@inria.fr>> 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.
Glad to see we have the same definition of traits.
Yet I will object on your assumptions: I am talking metamodeling, you
are talking programming.
Long time ago, there was a warning on not using inheritance for reuse
but for subtyping (and it even came out of Smalltalk that used to
"cancel" some of the inherited methods of a class).
I want to talk about multiple INHERITANCE because I want to talk about
subtyping.
Metamodelling is abstract, a description of a "domain".
I want to be careful to describe things "the right way", meaning not for
implementation, but for understanding.
Because I believe that only by keeping as close as possible to the
domain (the concepts in our heads) we will have a proper implementation.
Basically we have the same idea of 1-to-1 mapping (see your answer
further down), but you are thinking of pharo as the programming language
and I was trying to think of Famix as the implementation language ...
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 :).
Everybody uses code generation everyday because compiling is just
generating to byte code.
So the question might be whether we can do without "[manipulating]
anything at the lower level", or else to find a way to manipulate
directly Famix entities in Pharo.
nicolas
--
Nicolas Anquetil -- RMod research team (Inria)
11 Apr
11 Apr
9:04 a.m.
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
On Apr 10, 2013, at 8:36 AM, Nicolas Anquetil <Nicolas.Anquetil(a)inria.fr> 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.
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.
But in the end, I am not too sure whether it makes sense to speak of Traits at this level
of abstraction.
We are currently aiming at multiple inheritance of both attributes+methods with the
aliasing/restriction mechanisms.
Is this traits?
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.
As for Alain's work.
I have it on my disk, but did not have the time to look at it yet.
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 <Nicolas.Anquetil(a)inria.fr>
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
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
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
12 Apr
12 Apr
1:32 p.m.
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.
Other could be solved by adding more properties to generic entities.
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).
- 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'
- 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
- 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. BelongsTo is not reified, neither is AnnotationInstances, ...
- 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.
- 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.
- 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.
- '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)
- 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).
nicolas
--
Nicolas Anquetil -- RMod research team (Inria)
13 Apr
13 Apr
9:08 a.m.
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:
give example
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. 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
15 Apr
15 Apr
11:12 a.m.
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 <Nicolas.Anquetil(a)inria.fr> wrote:
On 04/11/2013 09:04 AM, stephane ducasse wrote:
give example
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. 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
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
11:11 p.m.
On Apr 15, 2013, at 11:34 AM, Tudor Girba <tudor(a)tudorgirba.com> 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 <anne.etien(a)univ-lille1.fr> 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 <Nicolas.Anquetil(a)inria.fr> wrote:
_______________________________________________
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:
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 04/11/2013 09:04 AM, stephane ducasse wrote:
give example
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. 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
On Apr 12, 2013, at 1:32 PM, Nicolas Anquetil <Nicolas.Anquetil(a)inria.fr> wrote:
_______________________________________________
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"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On 04/11/2013 09:04 AM, stephane ducasse wrote:
give example
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. 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
16 Apr
16 Apr
7:08 a.m.
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 :).
Doru
On Apr 15, 2013, at 11:11 PM, stephane ducasse <stephane.ducasse(a)free.fr> wrote:
On Apr 15, 2013, at 11:34 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
--
www.tudorgirba.com
"Problem solving efficiency grows with the abstractness level of problem
understanding."
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 <anne.etien(a)univ-lille1.fr> 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 :
_______________________________________________
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:
_______________________________________________
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:
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 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
On Apr 12, 2013, at 1:32 PM, Nicolas Anquetil <Nicolas.Anquetil(a)inria.fr> wrote:
_______________________________________________
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"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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
1 p.m.
On Apr 16, 2013, at 7:08 AM, Tudor Girba <tudor(a)tudorgirba.com> 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 <stephane.ducasse(a)free.fr> wrote:
On Apr 15, 2013, at 11:34 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
--
www.tudorgirba.com
"Problem solving efficiency grows with the abstractness level of problem
understanding."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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 <anne.etien(a)univ-lille1.fr> 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 :
_______________________________________________
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
--
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:
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 <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
--
www.tudorgirba.com
"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
1:10 p.m.
Precisely :). This is exactly my point. Given that we want to use Smalltalk
as an executable language, we will get to see this code all the time, so we
do not want to depend on generation.
Doru
On Tue, Apr 16, 2013 at 1:00 PM, stephane ducasse
<stephane.ducasse(a)free.fr>wrote;wrote:
On Apr 16, 2013, at 7:08 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
--
www.tudorgirba.com
"Problem solving efficiency grows with the abstractness level of problem
understanding."
--
www.tudorgirba.com
"Every thing has its own flow"
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 <stephane.ducasse(a)free.fr>
wrote:
>
> On Apr 15, 2013, at 11:34 AM, Tudor Girba <tudor(a)tudorgirba.com> 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 <
anne.etien(a)univ-lille1.fr> 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 <
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
>>
>>
>>
>> --
>> 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:
>> 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 <
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
--
www.tudorgirba.com
"Every thing has its own flow"
_______________________________________________
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
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
7:24 p.m.
On Apr 16, 2013, at 1:10 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
Precisely :). This is exactly my point. Given that we
want to use Smalltalk as an executable language, we will get to see this code all the
time, so we do not want to depend on generation.
Especially if we run smalllint and others tools.
Doru
On Tue, Apr 16, 2013 at 1:00 PM, stephane ducasse <stephane.ducasse(a)free.fr>
wrote:
On Apr 16, 2013, at 7:08 AM, Tudor Girba <tudor(a)tudorgirba.com> 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 <stephane.ducasse(a)free.fr> wrote:
_______________________________________________
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"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Apr 15, 2013, at 11:34 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
--
www.tudorgirba.com
"Problem solving efficiency grows with the abstractness level of problem
understanding."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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 <anne.etien(a)univ-lille1.fr> 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 <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
--
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:
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 <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
--
www.tudorgirba.com
"Every thing has its own flow"
_______________________________________________
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
15 Apr
15 Apr
11:09 p.m.
On Apr 15, 2013, at 11:12 AM, Anne Etien <anne.etien(a)univ-lille1.fr> 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.
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 :
On Apr 12, 2013, at 1:32 PM, Nicolas Anquetil <Nicolas.Anquetil(a)inria.fr> wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On 04/11/2013 09:04 AM, stephane ducasse wrote:
give example
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. 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
16 Apr
16 Apr
4:15 p.m.
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
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)
The problem is how does this map to a Pharo implementation?
Because Pharo Traits are stateless and Pharo classes don't have "trait
inheritance"
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.
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)
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:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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
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
4089
days inactive
4096
days old
19 comments
5 participants
participants (5)
-
Anne Etien -
Esteban Lorenzano -
Nicolas Anquetil -
stephane ducasse -
Tudor Girba