If the state of the root task is changed, the root task removes all tasks and remakes the task list. But, if setState() is called, the root task doesn't do a special process. "setState" can not be called again and is called by the base task basically.
* Adds manager freely *
You may be able to register every manager classes that don't have the type, to the root object. For example, a category manager and a tag manager may be registered. Because this is type-UNSAFE way, I don't like it. But the XNA Framework uses this way for programability as "Service".
Until today, the XC think that such features are IMPLEMENTED BY THE VIRTUAL SERVICE. But the virtual service is not light and not easy. Should we think that the virtual service is the module communication edition of the site communication?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
Some new specs are under review. We need a study of the following.
* State *
XCube_Task may support "state" for FSM. Especially, the state of the root task has the special mean.
XCube_Task::getState($stateName);
XCube_Task::changeState($stateName);
XCube_Task::getState();
If the state of the root task is changed, the root task removes all tasks and remakes the task list. But, if setState() is called, the root task doesn't do a special process. "setState" can not be called again and is called by the base task basically.
* Adds manager freely *
You may be able to register every manager classes that don't have the type, to the root object. For example, a category manager and a tag manager may be registered. Because this is type-UNSAFE way, I don't like it. But the XNA Framework uses this way for programability as "Service".
$root->setManager($tag, $manager);
$root->getManager($tag);
Until today, the XC think that such features are IMPLEMENTED BY THE VIRTUAL SERVICE. But the virtual service is not light and not easy. Should we think that the virtual service is the module communication edition of the site communication?