Although most of the time the user will, most likely, use only 1 EntityManagerT, the library supports multiple to be defined. If the user defines more than one he may also want to use the same callback for different EntityManagerT instances.
There are some problems with the current implementation:
- if the callback is a function pointer, the user has no way to access EntityManagerT
- if the callback is used across multiple instances the user has no way to know which was used
The implementation should change to the following signature:
void delegate(scope EntityManagerT, Entity)
The EntityManagerT should be scope to prevent it from escaping. This currently has some issues with DIP1000 and @safe code. When passed as scope all accesses must be scope compliant, requiring all functions to be defined with scope. This is an issue because it does not make sense to define the methods as scope for general use. Templating the functions might works in cases, from what I've tested, but I don't know if it can work as a solution for the entire lib.
An alternative to this is to refactor EntityManagerT to be a struct and not a class. With the struct approach callbacks could be defined as:
void delegate(ref EntityManagerT, Entity)
This fixes almost all issues with not much refactoring needing to be made. The downside is that the user will have to work with raw pointers.
Although most of the time the user will, most likely, use only 1 EntityManagerT, the library supports multiple to be defined. If the user defines more than one he may also want to use the same callback for different EntityManagerT instances.
There are some problems with the current implementation:
The implementation should change to the following signature:
The EntityManagerT should be
scopeto prevent it from escaping. This currently has some issues withDIP1000and@safecode. When passed asscopeall accesses must bescopecompliant, requiring all functions to be defined withscope. This is an issue because it does not make sense to define the methods asscopefor general use. Templating the functions might works in cases, from what I've tested, but I don't know if it can work as a solution for the entire lib.An alternative to this is to refactor
EntityManagerTto be astructand not aclass. With thestructapproach callbacks could be defined as:This fixes almost all issues with not much refactoring needing to be made. The downside is that the user will have to work with raw pointers.