The relations are transitive with respect to how they propagate information,
otherwise things wouldn't be correct. I was suggesting that clients be able
to ask whether they directly inherit from another objects, or whether they
inherit indirectly.
Antisimetric (aRb and bRa ==> a = b). I guess this is true also.
> >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?
>
Yes and No, depending on the context. If p1 and p2 are top-level objects then
the answer is No. If they are both parts of a container presentation, then
the answer is yes, if they are contained in an "part" or "non-shared"
attribute.
>
> >> 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.
>
Will construct example in a separate message
> >> 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?
>
I think the confusion is that O is an object, not a number.
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