The interface to MM_Object contains 4 methods for each logical "type" that
an attribute of an object may take on.
set_object(MM_Attribute_Symbol, <type>);
add_object(MM_Attribute_Symbol, <type>);
remove_object(MM_Attribute_Symbol);
<type> get_object(MM_Attribute_Symbol);
For the special case that an attribute is multi-valued of type Object, we
have the following three methods which allow us to name the objects that
we are adding, removing, or getting from a multi-valued attribute.
add_object_with_name(MM_Attribute_Symbol, MM_Name_Symbol, Object*);
remove_object_with_name(MM_Attribute_Symbol, MM_Name_Symbol);
MM_Object* get_object_with_name(MM_Attribute_Symbol, MM_Name_Symbol);
Note the absence of a method:
set_object_with_name(MM_Attribute_Symbol, MM_Name_Symbol, Object*);
Now I understand why this isn't in the current version, as we are only supposed
to add objects to collections (multi-valued attributes), but an interesting
case arises which I think should be legal MTF.
Consider the following MTF:
// (1)
Generate_Report : Task {
subtask_connection = :And_Connection {
subtasks = Specify_account [MY_TAG],
Specify_perion : Account {
}; // specify period
}; // and connection
}; // generate report
// (2)
Specify_account : Task {
}; // specify account
Note that in elaborating the task Generate_Report (1), we come to an object
Specify_account that we are not yet ready to elaborate. Some time later we
would like to elaborate this task (2). This seems like a reasonable thing
to be able to do, but consider how we must implement it. We would have
to go ahead in (1) and create an object Specify_account (because the order
of objects in this collection is significant, and add_object_with_name always
adds to the end...) But Specify_account must be instantiated from some other
object. Since we have not yet seen the declaration (2), how do we know which
object to make the prototype of Specify_account?
Note also that we can't just do a syntactic analysis to "discover" forward
references in this case because the forward reference may not yet exist
if the designer has not thought through that far.
I believe that an MM_Object method
set_object_with_name(MM_Attribute_Symbol, MM_Name_Symbol, Object*);
would be useful here. When we came to the case in (1) we would create
Specify_account via the Model_Server method:
create_by_name
as opposed to:
instantiate
and then when we came to (2) we would invoke the set_object_with_name
method to *replace* the originally create_by_name'd Specify_account.
What do you guys think of this solution? Could we extend the object system
to accomodate it? Thanks.
-- kurt.