flixel
flixel copied to clipboard
HaxeFlixel
Give managers their own module
(https://github.com/HaxeFlixel/flixel/issues/1081) Managers, such as FlxTimerManager and FlxTweenManager should be in their own modules. They contain a lot of code, they are not used privately by the modules they are contained in, and they exist as separate instances.
I just had a fairly confusing time because I opened FlxTween and searched for "update()". I did not realise, but I had been taken to the FlxTweenManager update method instead of the FlxTween update.
Were I to have gone looking for FlxTweenManager, I would have expected to find it in it's own module alongside FlxTween, in the same package but not hidden inside the same file.
Not sure about this, I don't really see the issue with having them in the same module... These managers are not something the user is ever going to need / import, they're mostly internal... Perhaps they should be moved to the system package?
@Gama11 Just because a user generally accesses them through flxG doesn't mean a user does not access them. Most users will never ever ever touch FlxBasic, but that doesn't mean it should be hidden from them. Most user never manually import FlxCamera etc. etc.. Whether or not a user is likely to import something themselves just isn't relevant. Users directly use the managers regardless, and if managers become attached to states there will be even more reason to do so.
As to whether or not they should be in a different module, ask yourself why any two related classes are not put in the same module. Is the any reason to make an exception here?
Putting classes in the same module is generally a bad idea, even when one of the classes is small and the classes are closely related (and in this case, the managers aren't even small). Doing so makes a class harder to find (for both users and engine developers), it makes it unsafe to use many ide tools such as find and replace, it makes it harder to read, it makes import names unnecessarily longer, it's less robust as it's far more likely to require a refactor if the functionality changes, and it makes source control commits less informative.
All of the above stand for putting any two classes in the same module. Just because two classes are closely related, or that a user is unlikely to use one of the classes directly (which they are in this case, anyway) are not at all reasons to make an exception.
The one time I can think of where an exception can be made is when the second class is private and is used exclusively by the main class of the module. This is not the case, here.
I'm ok with letting this slide for a later release, unless it gets done by 02/01/16, I would be hesitant to merge this change for 4.0 release.
We could potentially make this change without breaking anything if we put typedefs in place that redirect to the new location.