FlxTypeText counterintuitive callback behaviour

[6J7KZg2f]

Currently FlxTypeText.onComplete:Void->Void is public, and "Callback" is an optional paramater of FlxTypeText.start().

However, leaving out the Callback paramater of start() causes onComplete to be overwritten with null, meaning the only time you could meaningfully set onComplete directly is after calling start() but before the animation completes.

We could check for null in start(), but that would prevent you from intentionally nulling the callback when calling start.

I propose either making onComplete private, or removing Callback from start().

I personally lean towards the latter, as it creates less-messy function calls.

Thoughts?

[Gama11]

Actually, it seems this was a deliberate change a while ago: #293

[6J7KZg2f]

Okay, in that case what about leaning towards the former of my propositions?

This code:

var myFTT = new FlxTypeText(0, 0, 0, "test");
myFTT.onComplete = function(){trace("yeah nah");};
myFTT.start();

Surely should result in yeah nah appearing in the console.

If that is incorrect usage, I don't believe onComplete should be public.

[Gama11]

@winterismute Any thoughts on this, since you made the change originally? Is this a case you considered?

[winterismute]

The fact is that, depending on the mental model of the person that wants to use the class FlxTypeText, both using null to "force the callback to null" or not to do it might appear as sensible options for the behaviour of "start". I think at this point the best thing would be to remove the parameter from "start" and just have people set it explicitly if they want to use it, so that this does not interfere with the call to "start". A callback parameter could be potentially added to the constructor if we think a common usage of the object might be "attach a callback that you want to have called every time you restart".

[migmoog]

Can this be closed now after #353 ?