7 Mar
2013
7 Mar
'13
2:14 p.m.
I believe I already said here that I don't like very much the "default"
FAMIX metamodel in Moose because it is the union of Smalltalk and Java
specificities.
For 2 languages it works (more or less), but if we want to add C#, C++,
and whatever-else (not talking about non OO languages), it quickly
starts to be a huge mess.
It would be preferable to have a generic metamodel and specific ones for
each languages.
But then, we will run into cases where we want to have some kind of
multiple inheritance.
For example we could want to say that a Java method and a C function are
behaviouralEntities with return type and Java methods and Smalltalk
methods are behavioural entities with a received (when they are called)
and Java method now have two superclasses.
So the question arise why Fame does not have multiple inheritance?
- no specific reason?
- fundamental design decision?
- historical reason?
nicolas
--
Nicolas Anquetil -- RMod research team (Inria)
7 Mar
7 Mar
2:45 p.m.
Hi,
We do not want to use multiple inheritance as a design tool. We should use
Traits instead, as we know it scales better.
Alain Plantec already did a prototype for having Traits in Fame, but it was
not integrated. It would be great if someone would look into this. The only
thing to keep in mind is that we would have to also update the Java version
of Fame.
Cheers,
Doru
On Thu, Mar 7, 2013 at 2:14 PM, Nicolas Anquetil
<Nicolas.Anquetil(a)inria.fr>wrote;wrote:
I believe I already said here that I don't like very much the "default"
FAMIX metamodel in Moose because it is the union of Smalltalk and Java
specificities.
For 2 languages it works (more or less), but if we want to add C#, C++,
and whatever-else (not talking about non OO languages), it quickly starts
to be a huge mess.
It would be preferable to have a generic metamodel and specific ones for
each languages.
But then, we will run into cases where we want to have some kind of
multiple inheritance.
For example we could want to say that a Java method and a C function are
behaviouralEntities with return type and Java methods and Smalltalk methods
are behavioural entities with a received (when they are called) and Java
method now have two superclasses.
So the question arise why Fame does not have multiple inheritance?
- no specific reason?
- fundamental design decision?
- historical reason?
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"
4:05 p.m.
On 03/07/2013 02:45 PM, Tudor Girba wrote:
Hi,
We do not want to use multiple inheritance as a design tool. We should
use Traits instead, as we know it scales better.
do we? :-)
We were discussing this over lunch with Damien Cassou (our trait expert)
It seems to me traits are a behaviour reuse mechanism, Famix is mostly
about typing and structure.
Maybe conclusions drawn from programming languages implementation do not
apply to models.
I don't think models are just another kind of programming language, they
were primarily intended to be conceptual tools that could be derived to
programs.
A programming language must be implementable on a computer (or fail to
present much interest).
A model must be mostly transformable into a program, but some manual
tweaking seems acceptable.
nicolas
Alain Plantec already did a prototype for having Traits in Fame, but
it was not integrated. It would be great if someone would look into
this. The only thing to keep in mind is that we would have to also
update the Java version of Fame.
Cheers,
Doru
On Thu, Mar 7, 2013 at 2:14 PM, Nicolas Anquetil
<Nicolas.Anquetil(a)inria.fr <mailto:Nicolas.Anquetil@inria.fr>> wrote:
I believe I already said here that I don't like very much the
"default" FAMIX metamodel in Moose because it is the union of
Smalltalk and Java specificities.
For 2 languages it works (more or less), but if we want to add C#,
C++, and whatever-else (not talking about non OO languages), it
quickly starts to be a huge mess.
It would be preferable to have a generic metamodel and specific
ones for each languages.
But then, we will run into cases where we want to have some kind
of multiple inheritance.
For example we could want to say that a Java method and a C
function are behaviouralEntities with return type and Java methods
and Smalltalk methods are behavioural entities with a received
(when they are called) and Java method now have two superclasses.
So the question arise why Fame does not have multiple inheritance?
- no specific reason?
- fundamental design decision?
- historical reason?
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)
5:08 p.m.
Yes, we do :).
A model without the appropriate behavior has little value. For example, we
want to have traversals next to the model. It is for this reason that we
should use Traits.
Cheers,
Doru
On Thu, Mar 7, 2013 at 4:05 PM, Nicolas Anquetil
<Nicolas.Anquetil(a)inria.fr>wrote;wrote:
On 03/07/2013 02:45 PM, Tudor Girba wrote:
Hi,
We do not want to use multiple inheritance as a design tool. We should
use Traits instead, as we know it scales better.
do we? :-)
We were discussing this over lunch with Damien Cassou (our trait expert)
It seems to me traits are a behaviour reuse mechanism, Famix is mostly
about typing and structure.
Maybe conclusions drawn from programming languages implementation do not
apply to models.
I don't think models are just another kind of programming language, they
were primarily intended to be conceptual tools that could be derived to
programs.
A programming language must be implementable on a computer (or fail to
present much interest).
A model must be mostly transformable into a program, but some manual
tweaking seems acceptable.
nicolas
Alain Plantec already did a prototype for having Traits in Fame, but it
was not integrated. It would be great if someone would look into this. The
only thing to keep in mind is that we would have to also update the Java
version of Fame.
Cheers,
Doru
On Thu, Mar 7, 2013 at 2:14 PM, Nicolas Anquetil <
Nicolas.Anquetil(a)inria.fr> wrote:
--
www.tudorgirba.com
"Every thing has its own flow"
I believe I already said here that I don't like very much the "default"
FAMIX metamodel in Moose because it is the union of Smalltalk and Java
specificities.
For 2 languages it works (more or less), but if we want to add C#, C++,
and whatever-else (not talking about non OO languages), it quickly starts
to be a huge mess.
It would be preferable to have a generic metamodel and specific ones for
each languages.
But then, we will run into cases where we want to have some kind of
multiple inheritance.
For example we could want to say that a Java method and a C function are
behaviouralEntities with return type and Java methods and Smalltalk methods
are behavioural entities with a received (when they are called) and Java
method now have two superclasses.
So the question arise why Fame does not have multiple inheritance?
- no specific reason?
- fundamental design decision?
- historical reason?
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
8 Mar
8 Mar
8:10 a.m.
On Mar 7, 2013, at 5:08 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
I do not see why we could not use traits to make fame modular.
Yes, we do :).
A model without the appropriate behavior has little value. For example, we want to have
traversals next to the model. It is for this reason that we should use Traits.
Yes
We do not want to use multiple inheritance as a design tool. We should use Traits
instead, as we know it scales better.
do we? :-)
We were discussing this over lunch with Damien Cassou (our trait expert)
It seems to me traits are a behaviour reuse mechanism, Famix is mostly about typing and
structure. Maybe conclusions drawn from programming languages
implementation do not apply to models.
why would it be the case?
I don't think models are just another kind of
programming language, they were primarily intended to be conceptual tools that could be
derived to programs.
A programming language must be implementable on a computer (or fail to present much
interest).
A model must be mostly transformable into a program, but some manual tweaking seems
acceptable.
It depends and I do not see the point.
nicolas
Alain Plantec already did a prototype for having Traits in Fame, but it was not
integrated. It would be great if someone would look into this. The only thing to keep in
mind is that we would have to also update the Java version of Fame.
Cheers,
Doru
On Thu, Mar 7, 2013 at 2:14 PM, Nicolas Anquetil <Nicolas.Anquetil(a)inria.fr>
wrote:
I believe I already said here that I don't like very much the "default"
FAMIX metamodel in Moose because it is the union of Smalltalk and Java specificities.
For 2 languages it works (more or less), but if we want to add C#, C++, and whatever-else
(not talking about non OO languages), it quickly starts to be a huge mess.
It would be preferable to have a generic metamodel and specific ones for each languages.
But then, we will run into cases where we want to have some kind of multiple
inheritance.
For example we could want to say that a Java method and a C function are
behaviouralEntities with return type and Java methods and Smalltalk methods are
behavioural entities with a received (when they are called) and Java method now have two
superclasses.
So the question arise why Fame does not have multiple inheritance?
- no specific reason?
- fundamental design decision?
- historical reason?
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
9:41 a.m.
On 03/08/2013 08:10 AM, stephane ducasse wrote:
The points is: we know that multiple inheritance is a pain in the back
to implement in programming language.
Yet, we also know that everything everywhere uses something that in lack
of better image I would call multiple inheritance.
So I would like to see if we can define some kind of multiple
inheritance to describe things (fame/famix), and then some clever
mechanism to translate this multiple inheritance into real program
(pharo, java, whatever).
nicolas
On Mar 7, 2013, at 5:08 PM, Tudor Girba <tudor(a)tudorgirba.com
<mailto:tudor@tudorgirba.com>> wrote:
I do not see why we could not use traits to make fame modular.
I did not say I
don't want to use it
But I don't believe it covers all the needs.
For me a model and therefore Famix is inherently typed because it is
about describing things.
For exmple I fighted with Usman and Guillaume because they were using
FamixReference to represent an import between two programs when it
should have been some other association.
It worked, but it was not the right semantic.
And models are essentially tools to describe semantics, not implementation.
This is why I don't think traits are the solution in this case.
They are a reuse mechanism, not a typing one.
Yes, we do :).
A model without the appropriate behavior has little value. For
example, we want to have traversals next to the model. It is for this
reason that we should use Traits.
Yes
We do not want to use multiple inheritance as a design tool. We
should use Traits instead, as we know it scales better.
do we? :-)
We were discussing this over lunch with Damien Cassou (our trait
expert)
It seems to me traits are a behaviour reuse mechanism, Famix is
mostly about typing and structure.
I
don't think models are just another kind of programming
language, they were primarily intended to be conceptual tools
that could be derived to programs.
A programming language must be implementable on a computer (or
fail to present much interest).
A model must be mostly transformable into a program, but some
manual tweaking seems acceptable.
It depends and I do not see the point. >>
>> Alain Plantec already did a prototype for having Traits in Fame,
>> but it was not integrated. It would be great if someone would
>> look into this. The only thing to keep in mind is that we would
>> have to also update the Java version of Fame.
>>
>> Cheers,
>> Doru
>
--
Nicolas Anquetil -- RMod research team (Inria)
10 a.m.
Hi Nicolas,
I definitely do not want multiple inheritance in Fame. I do not see what you can model
with multiple inheritance and cannot model.
I think the problem you seem to see comes from you not perceiving Traits as Types. But,
they are types, just like classes are. And they should be captured as types in Fame as
well. Perhaps we can even make the MetaDescription be a Trait by default and have no
distinction between Class and Trait at the level of Fame.
Furthermore, the pragmatic reasons for using Traits should not be ignored lightly: Traits
exists as first class in Pharo, which makes it straightforward to map the TraitDescription
to the actual implementation. This is a huge plus.
So, I want to explore the Traits as an option before we discard it. And we already have an
implementation, as I mentioned.
Cheers,
Doru
On Mar 8, 2013, at 9:41 AM, Nicolas Anquetil <Nicolas.Anquetil(a)inria.fr> wrote:
On 03/08/2013 08:10 AM, stephane ducasse wrote:
The points is: we know that multiple inheritance is a pain in the back to implement in
programming language.
Yet, we also know that everything everywhere uses something that in lack of better image
I would call multiple inheritance.
So I would like to see if we can define some kind of multiple inheritance to describe
things (fame/famix), and then some clever mechanism to translate this multiple inheritance
into real program (pharo, java, whatever).
nicolas
--
www.tudorgirba.com
"We are all great at making mistakes."
On Mar 7, 2013, at 5:08 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
I do not see why we could not use traits to make fame modular.
I did not say I
don't want to use it
But I don't believe it covers all the needs.
For me a model and therefore Famix is inherently typed because it is about describing
things.
For exmple I fighted with Usman and Guillaume because they were using FamixReference to
represent an import between two programs when it should have been some other association.
It worked, but it was not the right semantic.
And models are essentially tools to describe semantics, not implementation.
This is why I don't think traits are the solution in this case.
They are a reuse mechanism, not a typing one.
Yes, we do :).
A model without the appropriate behavior has little value. For example, we want to have
traversals next to the model. It is for this reason that we should use Traits.
Yes
We do not want to use multiple inheritance as a design tool. We should use Traits
instead, as we know it scales better.
do we? :-)
We were discussing this over lunch with Damien Cassou (our trait expert)
It seems to me traits are a behaviour reuse mechanism, Famix is mostly about typing and
structure. I
don't think models are just another kind of programming language, they were primarily
intended to be conceptual tools that could be derived to programs.
A programming language must be implementable on a computer (or fail to present much
interest).
A model must be mostly transformable into a program, but some manual tweaking seems
acceptable.
It depends and I do not see the point. >>
>> Alain Plantec already did a prototype for having Traits in Fame, but it was not
integrated. It would be great if someone would look into this. The only thing to keep in
mind is that we would have to also update the Java version of Fame.
>>
>> Cheers,
>> Doru
--
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
8:07 a.m.
On Mar 7, 2013, at 2:14 PM, Nicolas Anquetil <Nicolas.Anquetil(a)inria.fr> wrote:
I believe I already said here that I don't like very much the "default"
FAMIX metamodel in Moose because it is the union of Smalltalk and Java specificities.
For 2 languages it works (more or less), but if we want to add C#, C++, and whatever-else
(not talking about non OO languages), it quickly starts to be a huge mess.
It would be preferable to have a generic metamodel and specific ones for each languages.
But then, we will run into cases where we want to have some kind of multiple
inheritance.
For example we could want to say that a Java method and a C function are
behaviouralEntities with return type and Java methods and Smalltalk methods are
behavioural entities with a received (when they are called) and Java method now have two
superclasses.
So the question arise why Fame does not have multiple inheritance?
simplicity at the time as reaction of MOF2.0
- no specific reason?
- fundamental design decision?
- historical reason?
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
4307
days inactive
4308
days old
7 comments
3 participants
participants (3)
-
Nicolas Anquetil -
stephane ducasse -
Tudor Girba