HaxeFlixel
Take ()->FlxState in FlxG.switchState
In it's current form: FlxG.switchState(new PlayState()) the state's constructor is called immediately, and the stateSwitch happens later, hence why we have create(). I'm proposing this should take a function that returns a newly created FlxState instance. This would allow devs to put all of their init logic in the constructor, where as of now this pattern would cause issues, since the constructor is called while the old state is still active.
This will also allow us to call FlxG.resetState with states that have constructor args
Similarly, the initialState passed in the FlxGame constructor should also be changed to a function.
Easy migration guide
// old code --> new code
FlxG.switchState(new PlayState()); /* --> */ FlxG.switchState(PlayState.new);
FlxG.switchState(new PlayState(levelID)); /* --> */ FlxG.switchState(PlayState.new.bind(levelID));
This is literally gonna break every demo
Recommended by @Gama11
Got a question, will this have backwards thingy? like, two options or just like make this as definitive?
no backward compatibility, this is a breaking change and it's gonna fuck shit up. but it's better in the long run.
TBH I like the idea that this will ensure everyone has breaking changes when they upgrade to 5.0.0, this should force most people to read the migration wiki that I will eventually make.
Also I plan to release 5.0.0beta with everything except this change, so people can ease into the changes.
Also I plan to release 5.0.0beta with everything except this change, so people can ease into the changes.
how about in the beta make a tweening on the old and new way, so that they can use the old but get deprecations and the new one, and on final release be like, boom gone
I don't know what tweening means, in this context, I don't know how i would make this backward compatible without doing some hacky stuff breaking typeSafety, and I do think forcing migration is better than silently changing everything
I don't know what tweening means, in this context, I don't know how i would make this backward compatible without doing some hacky stuff breaking typeSafety, and I do think forcing migration is better than silently changing everything
basically like, making a backwards compatibility for the beta, but it will be a deprecated warning like warning that in the final release, it will change, or something like that
do you have a suggestion? I can't think of a way to accomplish that
I'm thinking of a way but it would be runtime, not compilation warning tbh
@Geokureli I need to ask this just in case, the () -> FlxState is supposed to make create() deprecated or something like that?
cos I've been trying to add them together but it's been hard to make them work together seamlessly
I imagine the flow will be
- set FlxG.state to null and destroy the previous state
- instantatiate the new state
- set FlxG.state to the new state
- call state.create()
for 99% of the cases people can put all init logic in the state's constructor, but if they depend on a global reference to the state for some reason they can use create()
came here from this, I'm assuming with this breaking change, error logging will be objectively better than it is now? just curious, that's all!
came here from this, I'm assuming with this breaking change, error logging will be objectively better than it is now? just curious, that's all!
sorry for the late reply, this will prevent errors caused when instantiating flixel objects in a FlxState's constructor, or referencing global flixel tools in a FlxState's constructor. this will effectively remove the need for the create method which will open up the door for other possibilities.
Edit: this will also allow FlxG.resetState to be called on states with constructor args