Ok, I hadn't thought of that.
>I was assuming that once an object is created, its type is never changed, so
>that all modifications could be done to the structure that was already in
>place.
How do we do this if Specify_account should actually be instantiated from
an object that is a sub-class of Task? In this case, we will literally
need more slots than the original object had.
>If we want to support type mutation, we will have to move to a
>representation that has a header object that never changes, that that all
>pointers are kept intact when the type mutates. This wouldn't be hard to add,
>but why do it now, given that there is another solution for the problem at
>hand.
If we want to support the class based inheritance, we might have to do this.
>So, in your example, you have to create a Task object when you see
>Specify_account the first time. I think that is possible because it is a
>value of the subtasks attribute, otherwise the syntax would have to say:
>
>Generate_Report : Task {
> subtask_connection = :And_Connection {
> subtasks = Specify_account : TASK!!!!!!!!! [MY_TAG],
> Specify_perion : Account {
I should have used an example that instantiated from a subclass of Task
to make the point clearer. Sorry. Again in this case, the object
Specify_account could need more slots than are present in Task.
Any thoughts?
-- kurt.