Thread overview
Aedi - a dependency injection library
Aug 16, 2016
Alexandru Ermicioi
Aug 16, 2016
Jacob Carlborg
Aug 16, 2016
Alexandru Ermicioi
Aug 16, 2016
Rory McGuire
Aug 18, 2016
Alexandru Ermicioi
Aug 18, 2016
Rory McGuire
Aug 19, 2016
Eugene Wissner
Aug 19, 2016
Engine Machine
Aug 20, 2016
Alexandru Ermicioi
August 16, 2016
Good day.

I'd like to show my library aedi (v0.0.1), which implements dependency injection pattern.

They key features of aedi are:
1) Simple api through which a container can be configured with objects.
2) Ability to extend the library with custom logic required by your code.
3) Ability to inject already instantiated data (not only objects).
4) Possibility to build a hierarchy of containers that will be used to resolve dependencies. (for ex. if there is a need of a container that ships prototype objects along with singleton ones).

For more information about common usage of library, check readme.md on github.
Most of library is documented (functions, classes, interfaces, etc.). If there is some unclarity in docs, please tell about it.

https://github.com/aermicioi/aedi
https://github.com/aermicioi/aedi/blob/master/readme.md

The library is still in development, and I'd like to see some comments, on library's usability, as well possible improvements of it.

Thank you.

August 16, 2016
On 2016-08-16 11:41, Alexandru Ermicioi wrote:

> https://github.com/aermicioi/aedi

If you use:

```d
```

For the code block you'll get syntax highlighting for D.

-- 
/Jacob Carlborg
August 16, 2016
On Tuesday, 16 August 2016 at 14:25:10 UTC, Jacob Carlborg wrote:
> On 2016-08-16 11:41, Alexandru Ermicioi wrote:
>
>> https://github.com/aermicioi/aedi
>
> If you use:
>
> ```d
> ```
>
> For the code block you'll get syntax highlighting for D.

Thx, for info. Didn't know about such syntax. I'll update it with next batch of modifications.
August 16, 2016
On 16 Aug 2016 20:45, "Alexandru Ermicioi via Digitalmars-d-announce" < digitalmars-d-announce@puremagic.com> wrote:
>
> On Tuesday, 16 August 2016 at 14:25:10 UTC, Jacob Carlborg wrote:
>>
>> On 2016-08-16 11:41, Alexandru Ermicioi wrote:
>>
>>> https://github.com/aermicioi/aedi
>>
>>
>> If you use:
>>
>> ```d
>> ```
>>
>> For the code block you'll get syntax highlighting for D.
>
>
> Thx, for info. Didn't know about such syntax. I'll update it with next
batch of modifications.

Can this be used to do function
currying? http://stackoverflow.com/questions/36314/what-is-currying

Seems like an interesting feature. I imagine it would use templates or a wrapper struct instead of wrapped functions though.


August 18, 2016
On Tuesday, 16 August 2016 at 19:24:22 UTC, Rory McGuire wrote:
> On 16 Aug 2016 20:45, "Alexandru Ermicioi via Digitalmars-d-announce" < digitalmars-d-announce@puremagic.com> wrote:
>>
>> On Tuesday, 16 August 2016 at 14:25:10 UTC, Jacob Carlborg wrote:
>>>
>>> On 2016-08-16 11:41, Alexandru Ermicioi wrote:
>>>
>>>> https://github.com/aermicioi/aedi
>>>
>>>
>>> If you use:
>>>
>>> ```d
>>> ```
>>>
>>> For the code block you'll get syntax highlighting for D.
>>
>>
>> Thx, for info. Didn't know about such syntax. I'll update it with next
> batch of modifications.
>
> Can this be used to do function
> currying? http://stackoverflow.com/questions/36314/what-is-currying
>
> Seems like an interesting feature. I imagine it would use templates or a wrapper struct instead of wrapped functions though.

Thank you, for sharing with an idea :)

I'm not sure if I understand your proposition correctly.

I assume that you meant the call of register function on container to register an object in it. If so, by applying currying, we would get something like:

container.register!Type()("constructor")("setter", "setterArg"); // And so on.

It's an interesting idea, but I'm not sure if it will allow an easy customization of register api :(.

Could you please explain it in more detail?
August 19, 2016
On Thu, Aug 18, 2016 at 8:56 PM, Alexandru Ermicioi via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:

> On Tuesday, 16 August 2016 at 19:24:22 UTC, Rory McGuire wrote:
>
>> On 16 Aug 2016 20:45, "Alexandru Ermicioi via Digitalmars-d-announce" < digitalmars-d-announce@puremagic.com> wrote:
>>
>>>
>>> On Tuesday, 16 August 2016 at 14:25:10 UTC, Jacob Carlborg wrote:
>>>
>>>>
>>>> On 2016-08-16 11:41, Alexandru Ermicioi wrote:
>>>>
>>>> https://github.com/aermicioi/aedi
>>>>>
>>>>
>>>>
>>>> If you use:
>>>>
>>>> ```d
>>>> ```
>>>>
>>>> For the code block you'll get syntax highlighting for D.
>>>>
>>>
>>>
>>> Thx, for info. Didn't know about such syntax. I'll update it with next
>>>
>> batch of modifications.
>>
>> Can this be used to do function
>> currying? http://stackoverflow.com/questions/36314/what-is-currying
>>
>> Seems like an interesting feature. I imagine it would use templates or a wrapper struct instead of wrapped functions though.
>>
>
> Thank you, for sharing with an idea :)
>
> I'm not sure if I understand your proposition correctly.
>
> I assume that you meant the call of register function on container to register an object in it. If so, by applying currying, we would get something like:
>
> container.register!Type()("constructor")("setter", "setterArg"); // And
> so on.
>
> It's an interesting idea, but I'm not sure if it will allow an easy customization of register api :(.
>
> Could you please explain it in more detail?
>

No probs, example:
/////
module m1;
/// this module contains standard functions / classes etc...
auto func1(Type1 v1, Type2 v2, Type3 v3) {
    // do awesome stuff with all three instances
}

class A {
    Type4 v4;
    Type5 v5;
    this(Type4 v4, Type5 v5) {
        this.v4 =v4; this.v5=v5;
    }
    void changeMode(Type2 v2) {
        v4.asdf(v2);
    }
    void opApply(...) {
        /// do normal stuff with all these manually passed in instances
    }
}

module auto_deps_m1;
/// this module has the curryied versions of the original functions and
classes from m1;
/// What I think would be cool, and I thinks its possible, would be to
automatically inject default instance parameters into classes (the Object),
and functions.
/// so func1 could for example be exposed in this module as:
auto func1(Type2 v2) {
   /// yeah, don't worry about passing the other stuff in, it was all setup
during dependency registration
}

class A {
    Type4 v4; /// inject this
    Type5 v5;
    this(Type5 v5) {
        this.v5 = v5; // we never registered a Type5 during dependency
registration
        this.v4.changeMode(registered_v2); /// this got moved here due to
compile time dependency registration
    }
    void opApply(...) {
        // do stuff, and all we had to supply in other modules that depend
on this one is the instance for v5
    }
}

//////


The function example is what I was thinking initially, but I don't see why it couldn't be done with structs and classes as well.

I guess in m2 the code the programmer writes would be similar to:
mixin(registrationService.ct_register!(func1));

etc..

If its not possible right now I'd imagine its fairly close to possible.


disclaimer: I'm not very familiar with dependency injection in anything but Javascript with AngularJS.


August 19, 2016
On Tuesday, 16 August 2016 at 09:41:27 UTC, Alexandru Ermicioi wrote:
> Good day.
>
> I'd like to show my library aedi (v0.0.1), which implements dependency injection pattern.
>
> They key features of aedi are:
> 1) Simple api through which a container can be configured with objects.
> 2) Ability to extend the library with custom logic required by your code.
> 3) Ability to inject already instantiated data (not only objects).
> 4) Possibility to build a hierarchy of containers that will be used to resolve dependencies. (for ex. if there is a need of a container that ships prototype objects along with singleton ones).
>
> For more information about common usage of library, check readme.md on github.
> Most of library is documented (functions, classes, interfaces, etc.). If there is some unclarity in docs, please tell about it.
>
> https://github.com/aermicioi/aedi
> https://github.com/aermicioi/aedi/blob/master/readme.md
>
> The library is still in development, and I'd like to see some comments, on library's usability, as well possible improvements of it.
>
> Thank you.
How does it compare to poodinis?

August 19, 2016
On Friday, 19 August 2016 at 14:13:54 UTC, Eugene Wissner wrote:
> On Tuesday, 16 August 2016 at 09:41:27 UTC, Alexandru Ermicioi wrote:
>> [...]
> How does it compare to poodinis?

It has a better name!
August 20, 2016
On Friday, 19 August 2016 at 14:13:54 UTC, Eugene Wissner wrote:
> On Tuesday, 16 August 2016 at 09:41:27 UTC, Alexandru Ermicioi wrote:
>> Good day.
>>
>> I'd like to show my library aedi (v0.0.1), which implements dependency injection pattern.
>>
>> They key features of aedi are:
>> 1) Simple api through which a container can be configured with objects.
>> 2) Ability to extend the library with custom logic required by your code.
>> 3) Ability to inject already instantiated data (not only objects).
>> 4) Possibility to build a hierarchy of containers that will be used to resolve dependencies. (for ex. if there is a need of a container that ships prototype objects along with singleton ones).
>>
>> For more information about common usage of library, check readme.md on github.
>> Most of library is documented (functions, classes, interfaces, etc.). If there is some unclarity in docs, please tell about it.
>>
>> https://github.com/aermicioi/aedi
>> https://github.com/aermicioi/aedi/blob/master/readme.md
>>
>> The library is still in development, and I'd like to see some comments, on library's usability, as well possible improvements of it.
>>
>> Thank you.
> How does it compare to poodinis?

Thank you, for the question :) .

So here are some available options in aedi:
1) No injection into private properties directly (only through public methods). It won't tresspass object encapsulation.
2) Constructor injection.
3) Value type injection (See examples in readme.md).
4) Multiple instances of same type but configured differently.
5) High flexibility of library.
6) Composition of containers into hierarchical structure.
7) Mixing value typed data, with instantiated objects (thanks to composition of containers).

2,3)
Though, at the moment 2 and 3, are available through code api, not annotations (to be added in near future).
5)
Aedi, for construction of object instances uses Factory pattern, and so it does allow you to extend it by implementing your own instantiation logic into an object implementing Factory interface. Also it does allow further customization of created instances by PropertyConfigurers. The setter injection is achieved through it, while constructor injection through Factories.
Please view readme.md for more detailed explanation on how to add custom logic into containers.

Also, as described in readme.md, a container does not only hold an object, it manages lifetime of it as well. And aedi allows to create containers with more complex lifetime management, that should work nicely with rest of library (see 6).
7) Thanks to composition ability of containers, it is possible to add container (let's name it parameters container) of already instantiated data (objects, as well as value type data). This will allow the containers that instantiate objects to use, data contained in parameters container, that are objects as well as structs, functions, scalar values, etc.
Note: in 0.0.1 version, it is not complete, yet. On next batch of modifications (annotations), some changes will appear in code api, that will allow this to work at full capacity.

Currently, I'm working on annotation based container configuration. It will have following possibilities:
1) Component scan, per class, and module.
2) Registration and configuration of objects based, on static interfaces, and not concrete annotations.
3) Thorough manipulation with injected dependencies, as well as autowiring them.

2)
Since, the annotation based, registration will register by static interfaces, it will be possible for user code, to customize the registration process of objects, with their custom logic. To do so, the user will have to define their own annotation struct/class that will implement the required static interface.
Ofc, most of the options from previous list, will be available as well, to annotation based configuration.



Though, there are some features of poodinis that are not available in aedi :( .

Alexandru.