Thanks for the detailed answers to these questions. It helps a lot.
Naturally, I have some follow-ups :-)
>1) Semantics of "part" modifier.
>
>"deep copy of composite attributes" captures it well. So "part" is undefined
>and thus illegal for attributes whose values are not other objects.
>
>Suppose attribute A holds an object or collection of objects. Suppose X is an
>instance of Y.
>
>- If A is NOT a part attribute, then X.A and Y.A point to the same object
>(provided that the attribute is inherited via is-like or plays-role).
This seems like a potential source of confusion, as the MRL language has no
notion of pointers. Also, it seems that in this case an instance could change
an attribute and have that change reflected *backward* into a prototype.
This does not seem desirable. Why would you want to do this? If you never
want to do it, how can we protect against it?
>- If A IS a part attribute, the value of X.A is both is-like and plays-role of
>the value of Y.A. Later on, the is-like of X.A can be changed, but X.A still
>remembers that it plays role Y.A. Also, the attributes of X.A can be modified
>independently from the attributes of Y.A, which is not possible in the NOT
>part attribute case.
>2) Collections are really lists.
>Correct, and I would recommend changing the name sequence rather than list.
>Not high in the priority list, and I don't have a good feeling when it is
>best to do this.
Syntactic changes are easy. Particularly when they're just replacing one
keyword with another. I vote that we change this and the description keyword
change in (8) below the next time it is convenient to distribute a new version
of MRL.
>3) Is-like, plays-role and part all in the same attribute.
>I am not sure that is-liek and plays-role make sense at the same time,
This seems inconsistent with what you said in (1) above, when you said:
"- If A IS a part attribute, the value of X.A is both is-like and plays-role
of the value of Y.A. Later on, the is-like of X.A can be changed, but X.A
still remembers that it plays role Y.A..."
Doesn't this imply that an attribute can be both is-like and plays-role?
Or is there an object/attribute distinction that I am missing here?
>4) Delcaring an attribute as part, and then not declaring any inheritance will
>not produce the desired effect. The system should check that some inheritance
>is defined for part attributes. However, "whole" attributes don't require any
>inheritance.
This because they are pointers? If so, then wouldn't it be possible for
an instance to modify an object attribute and have this modification propagated
*backwards* to the prototype? Is this desirable?
It seems to me that semantically part really has two distinct meanings
depending upon whether the attribute is an Object or a Collection.
If the attribute is an object, part seems to mean "deep copy of composite
attribute". If the attribute is a collection, part seems to mean "dynamically
maintain corresponding elements in the prototype and instance collections".
This is different semantically because the former implies a "one time upon
instantiation" behavior, and the latter implies a dynamic constraint on the
structure of collections. In either case, the word part doesn't seem to
intuitively support the action being performed.
In the object case, for example, I think a better term might be "local" as
opposed to "shared" rather than "part" as opposed to "whole". Local
attributes have their own storage; whereas shared attributes are pointers.
In the collection case, I think of a part attribute as representing a schema
for dynamically adding attributes of a certain type. That is, a part collection
attribute really isn't an attribute so much as it is a container for some
unspecified number of attributes (is it even necessary that the container
is sequence ordered? Why not consider it a set?).
Is this picture in any way consistent with what you guys had in mind?
If in fact the word part is being overloaded for two distinct concepts, then
shouldn't we replace it with words appropriate to the particular concepts?
>5) Semantics of "class inheritance"
>
>I assume here we are talking about inheritance in the MRL spec.
>
>Object super {
> attribute foo : Double;
>}
>
>Object sub : super {
> ...}
>
>a) Relationship between instances is tricky.
>
>can sub-1 be is-like super-1 ---> No
>Only is-like between instances of identical classes should be allowed. If
>this is too contraining, we can think of smarter things to do.
No, this is intuitive. I also think that is-like should only apply to
instances of identical classes.
>8) Don't understand the question about Description, but anything that is
>reasonable should be ok.
Again, if no objection, we will make this change on the next update of MRL.
>- Single-line interpreter for MTF syntax. ==> Good idea. We discussed this in
>detail with Pablo and Ewald during CHI, and came up with an additional related
>issue.
>
>Say you load an MTF file into a model server, then you go the the text editor,
>edit it again and then ask the model server to reload it. What should happen?
>
>. I think that the effect of the second load should be that the state of the
>system is the same as if the file had never been loaded the first time.
>Objects should be destroyed as they are redefined.
>
>Do you agree?
Yes, I agree. The way I'm currently implementing the MTF parser back end,
it will be the responsibility of the object system to detect that a
redefinition is occuring and destroy the first copy. Is that a reasonable
expectation?
Thanks again.
-- kurt.