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.