Feature: World with components definable after initialization

[ameligrana]

For now a world can only contain components passed to it at initialization. I saw that Flecs allows also to pass components after that. We could also support that as an optional feature, creating an underlying RunTimeWorld or similar like so

mutable struct RunTimeWorld <: _AbstractWorld
    world::World
end

and if one does add_components!(world, (...)) (maybe also support remove_components!?) we use the still unimplemented #158 to reconstruct the world and then we swap it inside the RunTimeWorld struct. One will pay compile time again but if the user cooperates and uses function barriers no perf penalty should occur. In practice this means the user should unwrap the world autonomously though I think.

[ameligrana]

In a sense with #158 this is possible to do from the user side almost without problems, I'm not sure if we can actually offer something more than what I described

[mlange-42]

Yeah, it is rather unusual that components need to be specified on world construction. E.g., the Go Ark does not even require explicit registration at all, but does it on the fly when a component type is first used. I was a bit unhappy with this when we started the Larecs ECS, but meanwhile I see the advantages in terms of performance and (particularly) API convenience. In the Go Ark, I circumvent the component ID lookup issue by the requirement for permanently stored filters and component mappers.

So I think the quersion is under which circumstances it would be useful to add component types at runtime. Use cases I see are:

• Adding components to a game through mods
• Adding components to a model that is published as a library, to extend that model

In the latter case, it would also be possible to write the model's library in a way that the world is not contructed by the library itself in a hard-coded way, but thet users either pass a world, or additional required component types.

[ameligrana]

I also see mostly these kind of application and understand that the first one is the strongest. I think given that it doesn't require any restructuring supporting this feature seems a good idea