Refactor of Tween classes (calling start() is mandatory) - to address is...

[azrafe7]

...sue #128:

• all tween packages/classes are affected by these changes (misc, motion, sound, FP)
• the call to start() has been removed from tween()
• tween() returns the (specific) tween itself for chaining
• Tween.start() also returns the tween itself for chaining (you'd probably have to cast it to the proper tween)

Why? addTween(_someTween_, true/false) should now behave correctly.

I've tested it... maybe not thoroughly but... Any thoughts/comments about this?

[zachwlewis]

@jacobalbano @Draknek How does this change look to you guys?

[jacobalbano]

Looks good to me!

[Draknek]

I have no objection to returning useful values rather than null, but I can't see the argument for removing the call to start()?

I'm personally wary of breaking backwards compatibility.

[jacobalbano]

As I recall the issue is that if you call tween(), then add the Tween to a Tweener, it runs instantly even if you pass false as the autostart parameter. It's impossible to set up tweens ahead of time and run them later.

This is inconsistent with the Alarm class as well as being counter-intuitive.

[Draknek]

Hmm. Well there's the delay option to run them a known length of time later, but sure I can see how that'd be awkward.

My inclination would still be to save this up for a time when multiple other compatibility-breaking changes need to be made all at once, but it's @zachwlewis's call these days :)

[zachwlewis]

What about this change is not backward compatible? I'll need a list before I pull it in so I can have complete changelog notes. If this does need a major version bump, we might want to pull other big changes in as well.

[jacobalbano]

The incompatibility is whether a tween will start automatically when it is added.

As it is now:

addTween(myTween, false); // autostart = false, tween will be started anyway

This is true for anything but an Alarm. Alarms added with autostart = false have to be started manually.

[zachwlewis]

The incompatibility is whether a tween will start automatically when it is added.

So, there's no API change that will cause the game to just not compile? The incompatibility is that when people build their game with this change, Tweens will work the way they should've from the beginning? (I guess I'm still confused with the nature of this change.)

[azrafe7]

@jacobalbano recalls correctly. The topics that brought up the issue are these:

• http://developers.useflashpunk.net/t/whats-calling-tween-start/367/3
• http://developers.useflashpunk.net/t/knockback-how-to-get-the-direction-solved/1015

Buuut... I'd say not too merge this one, 'cause reexaming it now it doesn't fully makes sense to me, hehe 😬.

The problem still holds, but I'm not too happy of the way I handled it.

[azrafe7]

Oh... so here's the thought process. Forgot about it: #128

[AbelToy]

@zachwlewis There's no API change that would break the compiling, but the behaviour would be changed a little and games could act differently, resulting in not-expected behaviours during runtime.

[azrafe7]

As stated previosly: still I'm not happy with how it works as of now.

@jacobalbano said:

As it is now:

 addTween(myTween, false); // autostart = false, tween will be started anyway

Someone should probably look further into this and come up with a solution.