First of all I want to apologize for missing the Monday call. With Martin's
interview, I completely forgot about it, and only saw Spencer's phone message
late in the evening. Things have been quite crazy here, and only now did I
manage to get out of under all the brush fires.
1) Semantics of "part" modifier.
"deep copy of composite attributes" captures it well. So "part" is undefined
and thus illegal for attributes whose values are not other objects.
Suppose attribute A holds an object or collection of objects. Suppose X is an
instance of Y.
- If A is NOT a part attribute, then X.A and Y.A point to the same object
(provided that the attribute is inherited via is-like or plays-role).
- If A IS a part attribute, the value of X.A is both is-like and plays-role of
the value of Y.A. Later on, the is-like of X.A can be changed, but X.A still
remembers that it plays role Y.A. Also, the attributes of X.A can be modified
independently from the attributes of Y.A, which is not possible in the NOT
part attribute case.
2) Collections are really lists.
Correct, and I would recommend changing the name sequence rather than list.
Not high in the priority list, and I don't have a good feeling when it is best
to do this.
3) Is-like, plays-role and part all in the same attribute.
I am not sure that is-liek and plays-role make sense at the same time, but I
don't think that the object system should disallow it. However, I think that
here it would be ok to let the implementation drive the spec (ease and speed
of implementation should be the deciding factor).
4) Delcaring an attribute as part, and then not declaring any inheritance will
not produce the desired effect. The system should check that some inheritance
is defined for part attributes. However, "whole" attributes don't require any
inheritance.
5) Semantics of "class inheritance"
I assume here we are talking about inheritance in the MRL spec.
Object super {
attribute foo : Double;
}
Object sub : super {
...}
a) Relationship between instances is tricky.
can sub-1 be is-like super-1 ---> No
Only is-like between instances of identical classes should be allowed. If
this is too contraining, we can think of smarter things to do.
b, c, d) Can the sub redefine attributes defined in super. Again, let's say
NO. The sub cannot give additional info about attributes declared in the super.
The main effects of class inheritance are the following:
- Allows defining common attributes in a super class, so that they don't bneed
to be repeated in each of the sub-classes.
- If the type of an attribute is super, then it is legal to store in there a
sub. This allows us to have attributes that can store different, but related
kinds of objects.
6) example of hooks.
Don't have any yet, Do you? I assume that the hooks can call any of the
functions defined in the object system API.
7) Syntax for multiple hooks?
Don't know, but anything that gets the job done is fine with me.
8) Don't understand the question about Description, but anything that is
reasonable should be ok.
Questions from other messages:
- Idea of << >> for tags. Seems OK with me. We didn't use tags, but we are
not saying that we should drop them.
- Single-line interpreter for MTF syntax. ==> Good idea. We discussed this in
detail with Pablo and Ewald during CHI, and came up with an additional related
issue.
Say you load an MTF file into a model server, then you go the the text editor,
edit it again and then ask the model server to reload it. What should happen?
. I think that the effect of the second load should be that the state of the
system is the same as if the file had never been loaded the first time.
Objects should be destroyed as they are redefined.
Do you agree?
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