I want to discuss to changes in actions code. I specifically want Richard's feedback, because is related to code checked in by him, but if someone else has an opinion please chime in.
1) I want to remove actions.instant_actions.DoAction
Rationale:
I think it was introduced to deal with limitations in the old (0.3.0)
sequence operator, like the DoAction docstring tells:
"...Useful if you want to sequence actions of infinite duration."
The cocos 0.4 sequence operator was upgraded and now directly supports
sequencing when one of the actions can have potential infinite duration.
Thus, the example in the docstring:
action = Repeat( dance )
sprite.do( go_home + DoAction( action ) )
can be written
action = Repeat( dance )
sprite.do( go_home + Repeat( dance ) )
If you want an example with stock cocos,
rotate = RotateBy(360, 1 )
sprite.do( MoveTo(home, 2) + Repeat(rotate))
Thus, DoAction duplicates existing functionality.
And I think it is more clear 'go_home + Repeat( dance)' than 'go_home +
DoAction( Repeat(dance) )'
As it was only recently added in trunk, and never made to release, we don't
need to preserve for compatibility reasons.
2) I want to remove actions.interval_actions.Mover
Rationale:
The intentions for this code seems to be:
- allow external code to get access to the performing action
- control from external code some actions parameters
- move over a parabolic trajectory, have heading in consideration
The first point is achieved by cheating __deepcopy__ to return the action
itself, not a copy
But deepcopy is central to the current actions implementation:
i. used in all operators, and in particular Loop and Repeat will fail
with an action cheating as such
ii. it allows code like
action = MoveBy( (100, 0), 3)
node1.do(action)
node2.do(action)
to perform as expected, both nodes moving left by 100
An action cheating deepcopy will broke that
An there is an alternative way to allow external code to control action's
parameters without touching deepcopy:
cocosnode.do returns the action that will perform the changes, so the
external code can do:
action = ActionNotCheatingDeepcopy()
worker_action = node.do(action)
external code operates over worker_action
(Your code was intended to do:
mover = Mover()
external code operates over mover
)
I suspect that controlled actions (when external code changes actions
parameters in the action life) opens a whole new can of worms, like really
not working good with operators.
It can make sense at the app level, where the app context made clear there
are special actions, not intended to be operated, not to be performed by two
nodes, other restrictions my apply. And even at the app level I would not
use the deepcopy cheat: the alternative reminds what is the normal idiom to
refer to the performing action (like I need to know if I want to do
node.remove_action : node.remove_action(worker_action) works )
To summarize:
1) the deepcopy trick clashes with basic asumptions about actions
behavior
2) the normal way to acces the performing action is ignored
3) controlled actions are unchartered territory; to play fair with the
base actions we will need a base class for actions even more basic that
Actions, and see which operators can be allowed ( top of my head spawn is
plausible, but needs other implementation, Loop and Repeat seems less
plausible, and very tricky to implement)
4) it is normal for users to look the lib code to write his own custom
classes, and this will be steering them in the wrong direction in most of
cases
Should this action be retained in some form, it must be Action subclass, not
IntervalAction, and some warning added about why is a special case and not a
typical action.
I attach the example in test that uses Mover, modified to not use the
deepcopy cheat (drop in the test dir to have resources)
I you are ok, Richard, I can perform the relevant changes
--
claudio
--
You received this message because you are subscribed to the Google Groups
"cocos2d discuss" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/cocos-discuss?hl=en.
test_tiles_b.py
Description: Binary data
