-----------------------------------------
> >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?
>
When I say "point" to the same object, I mean that the value of both
attributes will be the same object. I think that is ok when one wants changes
to the object to be visible in all places. The reason to have "part"
inheritance is to obtain the bahavior where changes are not reflected
*backward*.
-----------------------------------------
> >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.
>
Sounds good to me.
-----------------------------------------
> >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?
>
No inconsistency here. The links between the objects are always maintained.
The inheritance annotations specify whether data can flow via these links,
which is independent of maintaining the links.
-----------------------------------------
> >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?
If you don't declare any inheritance, then the instaces of the object will not
have any value for the attribute, independent of whether the attribute is
marked as "part" or not.
>
> 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.
>
No, it is not "one time upon instantiation". One can start with no value in
the super, make an instance, and then specify a value for the super, which
will get instanced again in the subs of the original object. The idea is that
the "square diagram" gets maintained independently of the order in which
objects are created. The trickiets case is when a value gets supplied first
for the sub, and later on for the super. In that case, the plays-role link
needs to be updated to maintain the "square".
> 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.
>
I think the same terminology can be used in both cases. "part" or "shared"
are both good names, and I don't have strong preferences in that respect.
> 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?).
>
Yes, I think we both have the same idea. I didn't want to include different
kinds of collections (ordered, set) so that we can keep things simple. It is
a sequence, and get maintained as best as the system can.
> 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?
>
I think the concepts are similar. I think we should do a mini "user study",
ie, ask some friends to see which names are most understandable. We should
create a little example that illustrates the whole thing.
----------------------------------------
> >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.
>
OK, it is settled.
----------------------------------------
> >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?
>
Yes, I am not sure that the API currently has the ability to detect that a
redefinition is happening, but you are right, the problem is not a parsing
problem, and the model server should take care of this.
THis notion fits very well with some ideas I was discussing with Ewald
regarding the implementaiton of an undo mechanism for the object system. We
have a design for infinite undo that is very simple to implement. The basic
idea is that since there are so few calls in the API to change objects, it is
very easy to maintain a stack of "undo" records that contain the relevant info
for undo.
Once Ewald gets back we'll look into implementing this (because it is easy).
In the long run, it will be critical to have an undo mechanism, and since it
is so easy, we'll put it in now.
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