> >Yes, I was suggesting specializing the parser to understand Magnitudes better.
> My gut reaction is that this solution is not very orthogonal. The current
> MTF syntax is structured around the basic types (Long, Double, etc) and the
> composed types Object and Collection. If we then extend it to have special
> syntax for a *particular* object as opposed to objects in the abstract, then
> it seems that we would be compromising the level of abstraction between MTF
> and MRL. Now if we were to make Magnitudes a primitive type like Long or
> Double, then one might expect to see syntax for them in the MTF.
> But then that would be stacking the language in favor of one particular
> model...
>
> The extension is certainly doable, but I'm worried that it might not be what
> we want in the long run. What does everyone else think about this?
>
I understand your concerns, and leave it to your judgement and the opinion of
the others to figure out the best solution to this problem. I wouldn't mind
an "un-orthogonal" solution, if it is much easier to implement than some other
solution. In some sense, we would be making magnitudes a primitive, in the
sense tht the parser understands it, even though it is represented in the
model server as an object.
The other solution to the magnitudes problem is to make it a primitive in the
parser only, but not in the model. The parser would convert all magnitudes to
a standard set of units, say picas. So, Magnitude would be a typedef kind of
thing, represented as a float or double.
THe only shortcoming of this solution is that the model would not remember the
"preferred" units for a magnitude, given that internally it represents
everything in picas. However, the tools would be able to show the magnitudes
to the user in whatever units he or she wanted to see them.
What do you think of this solution?
Pedro Szekely
USC/ISI, 4676 Admiralty Way, Marina del Rey, CA 90292
Phone: 310/822-1511, Fax: 310/823-6714
URL: http://www.isi.edu/isd/szekely.html