26 Nov
2016
26 Nov
'16
12:36 p.m.
Hi,
As I mentioned at ESUG, I am really happy to see this effort, and I will support it.
Modeling is an important piece in Moose, and being more flexible at creating new models is
a significant added value given that Moose. Please keep me in the loop.
I am particularly interested in the object model of the meta-meta-model, and in the
mapping to the Pharo classes that contain the implementation of the meta-model. I believe
a Traits-based model would work well (I will try to list my ideas of how this could work
later).
Using Slots is definitely something we already should have done in Fame, and I think it
will work very well at least on the implementation level of the meta-model.
About syntaxes, I have less predilection for those, but I understand why they can be
appealing. I believe that we should first favor Pharo, and only afterwards other DSLs. For
example, if we insist of having the meta-model code separately, I believe that we should
be able to produce the meta-description also through a fluent API (so, the fluent API is
one of the syntaxes). Still, if we express the meta-model separately from the meta-model
implementation, the question is remains about how we do the mapping.
About types, I also disagree with the comment from Guillaume :). One place where types can
be relevant is when producing interfaces for editing objects, but I think that that does
not have to be the main driver of the design of the new meta-meta-model. The only thing
that I think is important when it comes to types is to allow us to reproduce the basic
meta-model implementation in other languages that do rely on rigid static types. For
example, right now, Fame generates the relations implementation using this information.
In any case, I do not necessarily have a predefined solution in my head, but I do have
requirements. And I would like to spend effort on this at least at the level of feedback
and prototyping.
Cheers,
Doru
On Nov 26, 2016, at 9:58 AM, stepharo
<stepharo(a)free.fr> wrote:
Hi
What we will try to do with Pavel, alain, anne and me (probably nicolas) in contact with
Peter starting january is the following
Define another metametamodel (trying to use Pharo + Slot for relationships + invariant =
Pharom)
- this metameta should be able to have different syntaxes
OpenPonk, Express, Pharo
- This metameta should does not need types :) sorry I did not get at all the remark of
guillaume
And in particular there is a difference between a static type and a concrete type
systems.
Take Famix 3 -> Famix3NG and break it appart to get composable pieces
and use Pharom to describe FamixNG
We are open to discussions but to a certain extent.
Then we will work on optimise for space.
In addition we will do a call to collect all the points that should be improve in
Moose.
We will
collect
prioritze
and tackle them
Stef
--
www.tudorgirba.com
www.feenk.com
"Yesterday is a fact.
Tomorrow is a possibility.
Today is a challenge."