> On the Georgia Tech side, we have been discussing the various features of the
> MRL language in order to begin preparing the MRL manual. From the discussion
> we have come away with a much clearer picture of how MRL works and also a
> feeling that we still don't understand some facets of the language. Could
> someone from ISI please answer the following questions? Thanks very
> much.
>
> 1) The MM_Object method: add_object_with_name seems to only be useful
> when adding objects to a "part" "multi-valued" attribute. Would
> you ever want to add elements to a general Collection by name
> in any but this case?
>
You underatanding matches ours. Only relevant for "part" "multi-valued"
attributes.
> 2) In the presentation MRL, there were no examples of Objects that
> made use of what we call "class-like" inheritence. That is,
> there were no:
> Object foo : bar {
> ...
> }
>
We did not make use of this feature because it is/was not implemented yet.
> declarations in the Presentation model. In order to write the MRL
> manual, we need to know the semantics of doing this. So assume we
> have the above definition of Object foo, and also the following:
>
> Object blech {
> attribute bar_slot : bar;
> }
>
> Now say I have at run time an object my_foo of type foo, and an
> object my_blech of type blech. Could I legally say:
>
> my_blech->set_object( bar_slot, my_foo )
>
> ???
> That is, does the object system support the more familiar subtyping
> inheritance as well as prototype-instance inheritance?
>
YES, definitely. THis is one of the main reasons to have this feature.
> 3) Let's say I have an MRL definition as follows:
>
> Object foo {
>
> part attribute Guides : Collection<guide>;
> part attribute Positions : Collection<position>;
>
> }
>
> And at run time, I have two objects foo1 and foo2 such that
> foo2 is an instance of the prototype foo1. Now let's say that
> in foo2 I add (or delete) one of the attributes in the Collection
> Positions. Obviously, this breaks the part relationship with
> foo1.Positions. So now I could add or delete an attribute
> in foo1.Positions, and it would have no effect upon foo2. But
> does it break off *all* connection with foo1? That is, if I now
> added a new guide to foo1.Guides, would I get a new guide in
> foo2.guides?
>
Good example, and I am curious to see if other people agree with my
interpretation.
Say this is the original state (is-like is represented as |, and plays-role as
^)
foo1 -- pos --> p1, p2
| ^ ^
| ^ ^
foo2 -- pos --> p11 p21
Now we add to foo2, so it looks like this
foo1 -- pos --> p1, p2
| ^ ^
| ^ ^
foo2 -- pos --> p11 p21 p3
So the connection between the p1 p2 and p11 and p21 remains intact.
Now we add p4 to foo1 so things look like this:
foo1 -- pos --> p1, p2 p4
| ^ ^ |^
| ^ ^ |^
foo2 -- pos --> p11 p21 p3 p41
So, the inheritance keeps updating the collection in foo1. Since p41 is
automatically added, it is both is-like and plays-role. In the first example,
with the initial state, I am assuming that p11 and p21 have their is-like
pointing somewhere else.
Now, if we used named values, and p4 happened to have the same name as p3,
then the diagram should look like this:
foo1 -- pos --> p1, p2 p4
| ^ ^ ^
| ^ ^ ^
foo2 -- pos --> p11 p21 p3
>
> 4) This question has to do with the granularity of specifying
> is_like (or plays_role) inheritance. Let's say in MRL I have
> two object declarations:
>
> Object Button {
> attribute Label : String;
> attribute Position : Integer;
> }
>
> Object Confirmation_Win {
> attribute Message : String;
> attribute Yes : Button;
> attribute No : Button;
> }
>
One thing: we would not have definitions like the ones above in an MRL file.
Buttons and windows would be defined in MTF as Presentation objects. The MRL
would contain the definition of presentation.
In the following answers I will assume that Button adn Confirnation_Win are
instances of Presentation, rather than being defined as MRL objects. I think
the questions refer to the possibility to further specify inheritance in the
instances, beyond what is defined in the MRL files.
Before I make a mistake here, let me talk to Pablo, and recast this example in
MTF terms.
> Now, we would like to say in the definition of Confirmation_Win
> that the Yes and No buttons inherit is_like. We can do this
> with the statement:
> is_like inherits(Yes,No)
> but that doesn't have much meaning since Button has no is_like
> inheritable attributes. What we really mean is that we want the
> Label attribute of the Yes button to always say "Yes" in all
> instances of Confirmation_Win (likewise for No). Can the object
> system support something like:
> is_like inherits( Yes.Label, No.Label )
> in the object declaration of Confirmation_Win? If not, then how
> would we express this problem in MRL so that we can make Yes and
> No buttons in the Confirmation_Win, and these buttons are is_like
> Button?
>
The following question was answered in a previous message.
> 5) (is_like vs. plays_role) In the context of the Guides attribute
> of Object Presentation (in pres.mrl),
> Given:
> MM_Object* pres = model_server->create("Presentation",
> Presentation);
> MM_Object* p1 = model_server->instantiate("Presentation",
> pres);
> MM_Object* p2 = model_server->instantiate("Presentation",
> p1);
>
> p1->set_object(Guides, ...);
>
> After this sequence of statements, which of the following are true?
> a) is-like(p1,pres)
> b) is-like(p2,pres)
> c) is-like(p2,p1)
> d) plays-role(p1,pres)
> e) plays-role(p2,pres)
> f) plays-role(p2,p1)
>
> We took the existence of plays-role to mean that we could change the
> guides attribute of a presentation and still be "is-like" a
> presentation.
>
> Now say that we did the following:
>
> p1->set_object(x_origin, ...)
>
> Assuming that in the def of Presentation there is the line:
>
> is_like inherits(x_origin)
>
> which of the following are true:
>
> a) is-like(p1,pres)
> b) is-like(p2,pres)
> c) is-like(p2,p1)
> d) plays-role(p1,pres)
> e) plays-role(p2,pres)
> f) plays-role(p2,p1)
>
>
> That's it for now. Thanks in advance for your answers.
>
> -- kurt.
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