Hmmm, I wasn't thinking about that. We really need to know the type of object.
Otherwise, a positional constructor could give too *few* attributes and
cause the creation of a super-class object when really a sub-class object
was intended. Even this case is tough.
>I assume that the parser first knows that it is looking at a MM_Guide. If the
>MM_Guide was not there, then the parser would have to assume some type. As I
>understant it, what you are suggesting is that for each attribute there is a
>default type of object to create. So for guides it would be MM_Guide.
Not exactly. I was suggesting using the type of the attribute name
(in our running example the attribute name was top_margin, and his type
was Magnitude) as a template for interpreting the positional constructor.
My thinking did not correctly handle the case in which a subclass object is
assigned to a slot of its super-class (which I think is the only complicated
situation here). Are you suggesting taking the approach that a positional
constructor defaults to the type that is assigned to the attribute (as opposed
to possibly some subclass of that type)? That should be doable.
>Your additional generalization is that one can say that for an atttibute, the
>values can be defined using a positional notation. Then the idea of saying
>"5 pixels" would work because the "position" attribute of "Guide" is declared
>to be of type "Magnitude", and the first to attributes in Magnitude are value
>and units. I am trying to re-state what you said to make sure we are in sync.
Yes, that's the impression I got when reading your original message.
Did you mean something else?
>Hmm, yes, doing the same trick for expressions would be very hard. We don't
>want to do type inferencing.
>
>How about a syntax where if you have NUMBER MAGNITUDE_UNITS, it creates a
>magnitude. So if the parser sees a number followed by one of the standard
>units, it parses it as a magnitude, independent of the rest of the context.
Not sure I understand this. Do you mean to specialize the mtf parser syntax
for one particular Object? Or do you mean to extend the mtf syntax to
understand multiplicities? If the latter, then I'd think we'd need some
additional MRL syntax to specify which objects/enums could have multiplicities.
Another thing here is the interpretation of value multiplicity. Does it assume
that there is an operator '+' for each type that uses the multiplicative
notation such that:
n V = V + V + ... + V
(n times)
This is becoming harder and harder to express in our framework...
Did you have something else in mind?
-- kurt.