Here is a list of planned features and events for the library: (The authors write it in their own free time, so concrete dates are hard to estimate)
- Possibly soon
- Create some library allocators: one with mem pages (vector memory), a per-frame style allocator, object pool style
std::list
one.
- Case-study: A demo project, that better illustrates the libraries functionalities in a "real life" scenario. Complete with a document which gives problems for motivation and their DynaMix solutions.
- Internal messsages: ways to notify mixins that their object was created or mutated (when all mixins are constructed)
- Remove arity from message macros
- Not soon, but with concrete idea of how to be done:
- Optimize mutation process: less allocations. Design special
mixin_collection
for the process, that can be preallocated (or that uses a buffer that's allocated only once) and has reserve
. Allow reuse of single_object_mutator
.
- private messages/mixins – messages/mixins that are not used outside of a module - leave more room for other messages/mixins
- Add a new mixin feature
fact
. Facts are static const variables in a mixin. No multicasts. No virtual tables.
- Reflection. Call messages by string.
- Make use of the fact that a significant performance improvement can be made if a user has no mixins or messages defined in a dynamic library (and has no plans to add such)
- Vectorized mixin/message memory: Instead of having a maximal number of them, grow the mixin_type_info/message_info buffers by that number. Might lead to slower mutations.
- Unused type garbage collector. When no objects exist of a given type it can be garbage collected, saving up to a kilobyte of memory.
- Create a preprocessing tool (like Qt's moc) that can be used instead of the macros for mixin and message definition.
- When humankind becomes a Kardashev type two civilization:
- Mixin/Message domains – sets of mixins and messages that cannot be mixed. Will throw a runtime error when trying to combine certain mixins or messages.