But how can you make sure that these default values are the same in all the languages.
This is equivalent to how all primitive values are set. If you have an attribute and you want to give it a value; you always need to translate the text in a way so that the language interpreting it understands it. "preferring a language" is not really relevant since you will probably always read it as a token first and then change tokens into actual values. The standard way of writing parsers.
Thanks for the lesson. (Toon could you consider that even if I ask extremely naive (or looking naive) question I'm not totally brainwashed, at least I believe so let me with my dreams.)
Apparently this is no what I understood from the first mse format. Adrian's first implementation used a literal array representation just to avoid to do the -TRUE- to true kind of conversion. Adrian can you comment on that?
Is it the importer that will do the mapping? I did that in CDIF converting idiot -TRUE- into true and this is boring and slowing everything.
As said before; this does -not- slow -anything- down. You always have to do that. If you write "true" in your workspace in Visualworks or whatever you use; you also have to read and parse this. It's not because it looks like the language does this automagically that your smalltalk does not read and parse it anyway.
I do not think that this is right :) but again I'm probably really naive about compiler and parsers. At least when the Smalltalk parser parses a literal array, it creates literal objects at compile-time and you do not have to do another translation. You sound really strong on your claim. I would really like that you show me that we are not losing more time with the translation approach.
'#(true nil (x true true false))' versus '-TRUE- NIL (X -TRUE- -TRUE- -FALSE-)'
Because I faced that in CDIF. But since I could not change CDIF I had to live with that. I had the impression that mse format was just to avoid the verbosity of XML and also the translation of such information. Now this is not a problem if the importer of moose gets slow. I was just asking this question for curiosity.
So mse will be slower or mse will favor a language (if this is Smalltalk this is ok too).
So this is an invalid argument. See above.
now if the default value is a boolean, will I get true or nil if in the model it was not set?
If no default is specified, this will be the default "unset" value of the language in question. In python this will be None, in java this will be null or 0 for int or false for boolean. For ...... and smalltalk this will be nil.
This would allow code generation in different platforms to actually write the correct initialization for those values.
I know I did that in 2000 for the DomainGenerator we never used. But this was fun to do that just to learn that old MOF way of representing relationship was crap and created overly complex queries for code generation.
Adrian implemented a code generator for FM3, I just finished doing the same in python, I also already have an mse-reader + writer in scheme; next week I will implement this in Smalltalk; and we use this to generate the FAMIX3.0 code so that they automatically support opposites with One/Many(for the one->one->many->many relations). Now we are working on a draft of the specification of MSE and FM3 in cooperation with Lukas.
FAME implementations available (for java and python) at: https://www.iam.unibe.ch/scg/svn_repos/Sources/Famix
cheers, Toon _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev