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?
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 {
...
}
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?
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?
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;
}
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?
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.