Re: plays role

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

>> Once again we've run into the infamous is_like/plays_role distinction.
>> In order to better understand the two mechanisms, we've put together
>> a few questions. The only example of plays_role that we have seen is the
>> guides attribute in object Presentation. Could someone from ISI please
>> answer the following questions in the context of that example? Thanks.
>>
>> 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)
>>
>The following are true:
>a) and c) by definition of instantiation.
>b) good question. Maybe the answer should be TRUE here, and there should be
>another method, called say is_like_direct, for which the answer should be
>false.

I think it makes sense that is-like and plays-role are anti-symmetric,
transitive relations. Isn't that how it's implemented now? That is, if
foo2 is-like foo1 is-like foo, and we make a change to an is-like attribute
of foo, doesn't that change get propagated down to foo2?

>Not true: d) e) and f).

I understand d and e not being true, but why not f? Shouldn't p2 still be
plays-role of 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.
>>
>Not sure I understand this. You can change the is-like of a guide to point to
>any other guide, and not lose track of the plays role pointer if one is
>defined.

Can you give me some sample C++ code to do this? I looked in the object system
implementation and saw methods to change the is-like pointer, but don't really
have a feel for when an implementation would do it. You had mentioned an
example when you were here with making an OK button in a confirmation window
be is-like an ICON rather than a BUTTON... Do you have any code examples
of this? Or if not, could you give the BUTTON example again? It seemed to
highlight the differences between is-like and plays-role, but I didn't really
understand it at the time.

>> 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)
>>
>This sounds like a trick question, because the anwers don't have anything to
>do with the question. Say you did p1->set_object(x_origin, O)
>
>a) p1.x_origin = O
>b) p2.x_origin = O
>
>If x_origin was a part attribute then b) would be false.

I was with you until this last statement. Wouldn't the fact that x_origin
inherits is-like ensure that the value 0 was propagated from the instance
p1 to the prototype p2?

Thanks.