I don't know, and it's probably because of a lack of examples. Some
background is probably in order. I've chosen to implement the MTF back-end
using some formal modeling techniques because the interactions can get
very complicated. I ran across this problem as a result of that analysis.
So does it come up in real applications? I'm not sure, but if you couldn't
use it here, wouldn't this be a pretty serious restriction on the use
of subclassing? That is, it would in effect force the designer to elaborate
subtasks that use class inheritance earlier than he or she would have
to elaborate subtasks that did not use class inheritance.
>- If you do, would it be too painful to include at least the class definition
>in the place where it is first introduced?
I don't think this solves the problem. We know the class definition by context.
The problem arises when we are using a class to generalize the behavior of
a set of objects. We declare that a multi-valued attribute is of type
Task so that we can stick *any* kind of task in there, be it an
application task or presentation task or whatever.
An example will probably be useful here.
My current version of the Task mrl uses class based inheritance to specialize
the class Task (into Application_Task and Interaction_Technique).
There is also an attribute subtasks in class Task that among other things
contains an attribute that is of type:
Sequence<Task>
Now let's think about a task called Read_Mail. Would we want the subtasks
attribute to contain both Application_Task's and Interaction_Technique's?
I think that we would. I would also think that when modeling Read_Mail
we might not yet be ready to model all of the Interaction_Techniques.
So we might use that feature here if we had it.
Noi, you're the task modeling expert. Is such behavior consistent with
what goes on during task modeling? Is this a case in which not having the
feature in question would be painful?
>I am against adding more features to the object system at this point unless
>there is no reasonable workaround with the current functionality. We have so
>many other things to do.
I agree. But I would like to settle the question, and if it's something we
think would be useful but don't want to implement right now, I'd like to:
1) Put a blurb about it in the documentation, and
2) Put some kind of warning in the MTF parser. Maybe the message:
Sorry, not implemented
something that is familiar to all C++ programmers :-)
Thanks.
-- kurt.