26 Nov
2016
26 Nov
'16
3:17 p.m.
On Sat, 26 Nov 2016 14:32:16 +0100, Tudor Girba <tudor(a)tudorgirba.com>
wrote:
Exactly. For example, MultivalueLinks that model the bidirectional
relationships in Fame work at the Pharo level and they do not care about
type. The static information is actually only meaningful when we
generate code.
Perhaps one option would be to have some sort of optional types for the
scenario in which someone would like to maintain these types. Or maybe
we find another solution.
Yes this is the point or deduce the Type because we rarely want abstract
types.
That makes sense. That is why I said that I am interested to spend
effort :).
Cheers,
Doru
--
www.tudorgirba.com
www.feenk.com
"What we can governs what we wish."
--
Using Opera's mail client: http://www.opera.com/mail/
Hi,
I mean that I would like a solution that openPonk and platypus can use
and that we can share the same metameta and if they prefer their own
syntax that they can use it.
From a end-user perspective may be usig openPonk or express is nicer than
pharo :)
On Nov 26, 2016, at 2:02 PM, stepharo
<stepharo(a)free.fr> wrote:
Hi doru
I think I am missing a part of the picture. What do you mean by
“stealing"? 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.
I kind of agree. Now I do not want to people feel that we still their
ideas and that
they get stuck with their syntaxes. 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.
Yes there is a difference between saying
- the type of "to" of this relation is Container
- the type of to of this relation is the class of the object that will
be the to of the relation
based on the instantiation of the relation.
It is like anchor-type. you may want to say
this variable is the same type as this one or the same type as
whaeveter.
and not hardcode the type once for all. 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.
Ok we do not have either a predefined solution.
Now we do not want to focus on interexchange constraints more on
empowering our infrastructure.
Cheers,
Doru
--
Using Opera's mail client: http://www.opera.com/mail/ 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."