Re: MRL questions.

Kurt Stirewalt ([email protected])
Fri, 19 May 1995 09:57:53 -0400

>> 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.

Thanks! This is a very enlightening exposition. I read from this that we can
never *break* the part relationship. I had at first thought that after adding
p2 to foo2.pos, adding to foo1.pos would have no effect on foo2. This example
clears that up nicely. Also, this example brings home my point in a previous
response that part seems to be overloaded. This behavior on collections
does not seem to have an analogue on objects.

As for the is-like/plays-role distinction, I think now that I'm getting
confused between is-like and plays-role between objects and is-like/plays-role
between attributes. We declare that attributes inherit is-like or plays-role,
but we speak of objects being is-like or plays-role other objects.
To clear up my misunderstanding, let me state what I think it means for two
objects to be is-like each other:

Conjecture: An object o1 is-like an object o2 if o1 and o2 are of the
same class, and *all* of the is-like attributes of o1 are
is-like *all* of the is-like attributes of o2.

Is that accurate? My conjecture implies that if even one of the is-like
attributes of o1 fails to be is-like the corresponding attribute of
o2, then o1 is now not is-like o2. Is this an accurate reflection on the
semantics of the object system? If not, then how would you define what it
means for two objects to be is-like using language similar to that of the
conjecture?

>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

This completely blows my mind :-) In fact, it sounds like more of a behavior
in the current implementation than something that one would consciously do.
Why does it establish the plays-role relationship only? Are there any examples
of when one would want to do this?

>>
>> 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.

Ok, I see your point. We were just trying to come up with an example that would
exercise the need for controlling inheritance at a grain finer than that of
an object.

Thanks again for the detailed answers. They are helping.

-- kurt.