memory_management

Aedi, a dependency injection library.

Aedi is a dependency injection library. It does provide a set of containers that do IoC, and an interface to configure application components (structs, objects, etc.)

Aim:

The aim of library is to provide a dependency injection solution that is feature rich, easy to use, easy to learn, and easy to extend up to your needs.

D by default comes with garbage collector which is responsible for destruction and deallocation of components that were used, and discarded by the application. Current implementation of garbage collector can be inefficient for cases when many small objects are continously created and destroyed by application. Therefore aedi framework allows users to select what allocation strategy to use for managed components by using std.experimental.allocator library.

To change the allocator used for components in a container, it is possible to pass new allocator implementation to configure method as third argument just like in example below:

with (container.configure("singleton", Mallocator.instance.allocatorObject)) {
    // ... registered components with Mallocator as allocator for them
}

The allocator passed in configure will be used as default implementation. As alternative syntax it is possible to pass the allocator in a fluent syntax by chaining along to configure with allocator as it's argument. Example below shows such variant:

with (container.configure("prototype").along(MmapAllocator.instance.allocatorObject)) {
    // ... registered components with Mallocator as allocator for them
}

The default allocator strategy can be overriden per component by directly specifying the allocator that should be used by registered component using allocator property for registered component. Example below shows such use case:

register!Size("size.sedan") // Register a size of a generic "sedan" into container
    .set!"width"(200UL)
    .set!"height"(150UL)
    .set!"length"(500UL)
    .allocator(MmapAllocator.instance.allocatorObject); // Change allocator object for this particular component to mmap allocator.

As a consequence to using custom allocation strategies, for all containers, terminate method should be called when containers lifetime ends (whether at end of application, or during some other event), otherwise it is not guaranteed that components are finalized correctly, even if they were allocated on garbage collector.