On 27 Nov 2007, at 20:05 , Toon Verwaest wrote:
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:
It is a mess, and maybe, in addition, the version on the new site is not based forked from the latest version on smallwiki. @Doru, when did you fork the new site?
- 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.
This was a bug.
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? 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?
Lets call them built-in types: Object, String, Number, Boolean and Date. In the mse file, you must not include them and can refer to them using named references, eg (ref: String). An implementation of named references must implement the lookup of names such that these built-in types precede any user defined name, ie it must be impossible to shadow these names.
- 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.
That needs more work, eg shadowing of attributes is not yet specified.
In general, multivalued properties are an unordered list of unique elements, ie set. Why? YAGNI, in Famix 2, even though there was support for bags, lists and ordered sets, nobody ever made use of that.
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?
java -ea -cp famix.jar Fetch fm3
(works with the latest version of famix.jar)
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.
Cool! Where is it available?
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".
Become is about an order of magnitude slower than doing a two pass import, in particular for large mse files (10 MB and more). Become is an extremely slow operation.
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 :)
true
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)
(... (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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev