alternative to D5198
just some WIP experiments
Differential D5246
WIP Refactor playerPlacement functions (another approach) marder on Feb 18 2024, 8:48 PM. Authored by
Details
Diff Detail
Event Timeline
Comment Actions The only thing I could find on phab was this: Generally PlayerPlacement should be called at most twice per-map creation, so the overhead should be ok, but I can do some tests as well. But also, just from the point of keeping an (somewhat) consistent codebase... Should we just stick to xy.prototype.method ? Comment Actions at least from a simple test (just object creation and setting a value) the performance looks equal. Not sure what happens in complex scenarios tho. Comment Actions That's the most likely outcome. https://medium.com/javascript-scene/why-composition-is-harder-with-classes-c3e627dcd0aa suggest classes can even be used for performance reason and lower memory consumption. Therefore blindly using bb's benchmark on an old SM as the general rule for all the future uses doesn't strike me as a good idea. Comment Actions unrelated to the class / prototype discussion, just a quick update to make it somewhat functional.
Comment Actions I don't like this interface: It's uncommon to store the result in this instead of returning it. The dataflow is hidden. Comment Actions Its indeed two step. But it enables const placement = new PlayerPlacement(); placement[g_MapSettings.TeamPlacement](args); which would make playerPlacementByPattern obsolete. I mainly wanted to try this since you mentioned here: https://code.wildfiregames.com/D5198#221356
I'll take your word for it. I have seen stuff like this, but I can't say if it is common or uncommon. Comment Actions As option C we can just stick to individual functions that return an object of class PlayerPlacement, instead of methods. Idk, I have a hard time to decide what is the more maintainable / clear. So I'm open for opinions. Comment Actions Well now there is also a global object but it's hidden in PlayerPlacement.prototype. If you really want to go without the global object you'd have to return it from PlayerPlacement(). But that's even worse IMO. |