28 Nov
2007
28 Nov
'07
4:50 p.m.
On 27 nov. 07, at 20:05, Toon Verwaest wrote:
Adrian Kuhn wrote:
Can you explain what you are doing?
What is the metarepository builder?
I am working on the handling of primitives in FM3
and Famix 3, and
would like to make a small survey on how primitives had been used in
Famix 2
- who used the custom primitives fature in Meta?
- who added a custom primitive other than Timestamp/Date/Time?
- which primitives are you missing?
I saw that dates are used in many projects (Chronia, Dude, etc...)
and hence suggest to include them in FM3 as built-in primitives. The
list of primitives is thus
String
Boolean
Number
Date (new)
with MSE format
string ::= ( "'" [^']* "'" )+
boolean ::= "true" | "false"
date ::= digit{4} "-" digit{2} "-" digit{2} ( ","digit{2}
":" digit
{2} ":" digit{2} )
number ::= "-"? digit+ ( "." digit+ )? ( "e" (
"-"? digit+ ))?
@toon, can you extend the MSEParser in Smalltalk to recognize this
token? I have only poor Store access here.
No problem. I will do that the end of this week or next week.
I do have a list of remarks on the mess of FM3 / MSE that is currently
online. There doesn't seem to be too much consistency anymore,
since the
things that have been changing recently. At the office I have a bigger
list of things; but things that I currently remember:
- you state that those primitive objects are the only ones which
shouldn't necessarily be defined in a package. I seem to recall
that at
some point we had entries like:
(MSE.Class (back then it was still mse) (id:...) (name: Boolean)) as a
toplevel statement; not in a package; to which we referred by id. Now
all of a sudden I see in the FM3 file that you have used ref: (which
looks like the primitive: in the EMOF version), but which is not
defined
in FM3. Does ref: mean that you do some lookup, or is this only for
primitives, or ... where does it come from? And where -did- those
primitive declarations go? They don't have to be declared anymore? I
didn't understand this by just looking at the available specification
online.
Oh, and then... object is not a primitive type. Which means that if
that
is the definition; object should be declared... so I guess you don't
have to write "the objects known to the reader" (reserved instances as
you call them), and are ref:-able?
- I started noticing while implementing my python-version of FM3, that
you only specify that the field attributes of class can not contain
attributes of the allAttributes of the superclass. Does this allow for
attributes to have duplicates? I haven't seen the word "set" on that
page. It just states "multivalued" which doesn't say anything about
the
actual values. Which is normal; because for normal models we probably
-do- want to be able to have duplicates.
- I just noticed that FAMIX3.0 spec is only online in EMOF? (or at
least, that is the only version I found in a quick search)
Shouldn't we
at least have an FM3 version somewhere?
Then the "good" news: today I finished a prototype implementation
of an
FM3 metarepository builder, which unlike the smalltalk version, builds
the repository in single pass, and doesn't use 10 different
dictionaries
for building it up. Actually, the builder itself hasn't got any
dictionary and fills up the model from scratch without doing
intermediate things itself. Actually; I guess that we can do a similar
single-pass MSE-reader for smalltalk (and maybe python too); which
shouldn't be too difficult if we use "become" to swap "most-specific
instances known up to a certain point" by "more specific instances".
For FM3 that isn't an issue since at all times we know the exact
type of
what should be were, even if it isn't read yet. The metarepository
builder is something special anyway :)
Then at some point I might put in that opposite/derived/type story I
told Adrian and Doru; if I am working on this anyway.
For those who are not following and still reading (you must be really
bored :P)
Indeed I was wondering if we should understand it.
(... (name "type1")
(property (name "prop1")
(derived true)
(type "type2")
(opp "prop2")
....)
(... (name "type2")
(property (name "prop2")
(type "type1")
(opp "prop1")
....)
has duplicated info and could be reduced to:
(... (name "type1")
(property (name "prop1")
(type "type2")
(opp "prop2")
....)
(... (name "type2")
(property (name "prop2")
....)
-> if you link to a prop of another type; that prop of that other type
automatically links back to you (prop) with as type, the class in
which
that prop was defined. The one stating the opposite link is
automatically the derived version.
1 special case: if a prop has itself as opposite (i.e. the opposite
property of FM3.Property), it is not derived.
This comes from the fact that while defining the original drafts for
FAMIX3.0, I had to type out this info. And having to copy all that
data
over and over again... is quite a hassle. And well, duplicated info is
never good anyway.
Enough for one mail.
Cheers,
Toon
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev