12 Apr
2013
12 Apr
'13
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)