The only thing I could find on phab was this:
https://code.wildfiregames.com/D4021#173216

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 ?

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.

Found it. https://irclogs.wildfiregames.com/%230ad-dev/2020-07-29-QuakeNet-%230ad-dev.log

20:52.

In D5246#223204, @marder wrote:

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.

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.

A better solution indeed would be to profile :)

I don't like this interface:
If one wants a PlayerPlacement one would have to call two functions.
That's a two step initialization. (Which is bad IMO)

It's uncommon to store the result in this instead of returning it. The dataflow is hidden.

In D5246#223211, @phosit wrote:

I don't like this interface:
If one wants a PlayerPlacement one would have to call two functions.
That's a two step initialization. (Which is bad IMO)

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
That we could put the function into an object to enable this syntax (but I didn't liked the idea to create another global object for this).

It's uncommon to store the result in this instead of returning it. The dataflow is hidden.

I'll take your word for it. I have seen stuff like this, but I can't say if it is common or uncommon.
It definitely isn't what you would do in a functional approach, but in oop (as far as my understanding goes) it would fit into the "Command-query separation" principle.

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.

In D5246#223218, @marder wrote:

(but I didn't liked the idea to create another global object for this).

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.