[announce] First alpha version released (as SNAPSHOT)

[Alois Cochard]

Greetings,

A first alpha version (0.1-SNAPSHOT) of SDI is available on my private maven repository, instructions and examples usage here :

https://github.com/aloiscochard/sdi

Don't hesitate to share your first impressions about the library.

Cheers,

--

Alois Cochard

http://aloiscochard.blogspot.com

http://twitter.com/aloiscochard

[Przemek Pokrywka]

Hi,

My first impression was "that's nice".
Unfortunately, it's a service locator (and hardcoded, sadly) and not
DI actually :(
Inject method gets imported to domain objects, and AFAIK this is not
something you can easily swap at runtime?
Then you don't have the ability to configure objects differently for
test and for production setups.
You only centralize your configuration and that is not DI.

Can you fix that? I'd like to be able to use different bindings for
tests and for production (at least).

regards,
Przemek

[Alois Cochard]

Hello Przemek,

Good news:

It's a real DI framework (otherwise this would have no interest at all in a language like scala), there is a parent-child relationship between injector (and indirectly context), enabling to override binding during runtime - BUT only before the injector you when to override get used, then binding is immutable.

It's basically the same idea as Pico/Guice/Spring, without this feature there is no advantage of using SDI vs cake pattern or other DI technics

Bad news:

It's not documented at all since I hacked this library in 3day and hadn't time to test and give example of this functionality.

Basically you call .childify on the context you want to override and you give the parent injector where the binding will override the actual injector.

It's not a 'swap' as you said, it's more a delegation and I think it's the only way to do thing right will keeping immutable data-structure.

The next feature I want to add, is the possibility to interface binding from a configuration, preventing you to create the boiler plate code to set the 'dev/prod' value in you configuration file for example.

Thanks a lot for your feedback and your interest, I'll send an example of binding overriding this evening.

Cheers,

[dholbrook]

I agree that this is a service locator, and not dependency injection.
It violates the Hollywood principle "don't call us, we'll call you".

That said there is no reason you couldn't use this to do manual
dependency injection to wire up your object graph. There is no reason
your plain old Scala objects need to know anything about the service
locator.


On May 26, 1:52 am, Przemek Pokrywka <przemyslaw.pokry...@gmail.com>
wrote:

[Alois Cochard]

Hello all,

I've just pushed a new examples showing the hierarchical feature, please take a look at this two file:

https://github.com/aloiscochard/sdi/blob/master/src/test/scala/sdi/examples/1_Module.scala

https://github.com/aloiscochard/sdi/blob/master/src/test/scala/sdi/examples/2_Application.scala

You can test it using console mode in SBT.

So could you please elaborate on the examples I've just gived, why it's not DI ?

Thanks a lot guys,

[Alois Cochard]

OK your are totally right.

Will try to get ride of the dependency by using constructor parameter.

This one helped me:

http://martinfowler.com/articles/injection.html

Thanks !

[dholbrook]

I was going to point you at the Fowler article.

I really like what you have here. You have some very inventive stuff
going on in your code.

Scala is a different beast than Java and I wonder if the reasons that
the Service Locator pattern was not the "winner" in Java land do not
apply to Scala.

For testing it is very easy to override a def, so if you make a
dependancy a def it should be easy to make a mock for testing. I
guess my point is that is is a perfectly good approach to IOC even if
this is not DI.

On May 26, 1:03 pm, Alois Cochard <alois.coch...@gmail.com> wrote:
> OK your are totally right.
>
> Will try to get ride of the dependency by using constructor parameter.
>
> This one helped me:http://martinfowler.com/articles/injection.html
>
> Thanks !
>

> On 26 May 2011 21:37, Alois Cochard <alois.coch...@gmail.com> wrote:
>
>
>
>
>
>
>
>
>
> > Hello all,
>
> > I've just pushed a new examples showing the hierarchical feature, please
> > take a look at this two file:
>

> >https://github.com/aloiscochard/sdi/blob/master/src/test/scala/sdi/ex...
>
> >https://github.com/aloiscochard/sdi/blob/master/src/test/scala/sdi/ex...

>
> > You can test it using console mode in SBT.
>
> > So could you please elaborate on the examples I've just gived, why it's not
> > DI ?
>
> > Thanks a lot guys,
>

> > On 26 May 2011 20:13, dholbrook <davidbholbr...@gmail.com> wrote:
>
> >> I agree that this is a service locator, and not dependency injection.
> >> It violates the Hollywood principle "don't call us, we'll call you".
>
> >> That said there is no reason you couldn't use this to do manual
> >> dependency injection to wire up your object graph.  There is no reason
> >> your plain old Scala objects need to know anything about the service
> >> locator.
>
> >> On May 26, 1:52 am, Przemek Pokrywka <przemyslaw.pokry...@gmail.com>
> >> wrote:
> >> > Hi,
>
> >> > My first impression was "that's nice".
> >> > Unfortunately, it's a service locator (and hardcoded, sadly) and not
> >> > DI actually :(
> >> > Inject method gets imported to domain objects, and AFAIK this is not
> >> > something you can easily swap at runtime?
> >> > Then you don't have the ability to configure objects differently for
> >> > test and for production setups.
> >> > You only centralize your configuration and that is not DI.
>
> >> > Can you fix that? I'd like to be able to use different bindings for
> >> > tests and for production (at least).
>
> >> > regards,
> >> > Przemek
>
> > --

> > *Alois Cochard*

> >http://aloiscochard.blogspot.com
> >http://twitter.com/aloiscochard
>
> --

> *Alois Cochard*http://aloiscochard.blogspot.comhttp://twitter.com/aloiscochard

[Przemyslaw Pokrywka]

Hi,

While I find the project quite interresting, its Service Locator nature is clearly a disadvantage.

I doubt whether SDI allows you to have several instances of a component configured differently at the same time. Please correct me, if I'm wrong.

Say I would need several UserServices, each with different Repository. Should I call childify multiple times?

Scala *is* different than Java in many areas, though problems of inproper DI are still relevant in this language. One of Service Locator's basic weaknesses is that it is shared by multiple components, that prevents them to be configured in a different way.

I'm waiting for that constructor parameter approach you've mentioned.

regards,

Przemek

[dholbrook]

At the heart of every DI container lies the beating heat of a service
locator. If you take a look at the spring BeanFactory the first half
of what it does is provide a service locator so that later it can read
xml or use reflection to do the actual injection part.

There is no reason a service locator can't use a custom scoping
mechanism to provide multiple implementations for a single interface,
or you could use the implementation type directory. That is exactly
what both Guice and Spring do.

What I'm wondering about is the need for external xml or reflection to
do the wiring when Scala DSLs do such a good job of that all on their
own.

Here is a gist of a trivial service locator (not even in the same
league as what Alois has done) showing how I thing you could use a
service locator with manual DI.

https://gist.github.com/994216


On May 26, 2:35 pm, Przemyslaw Pokrywka

[Alois Cochard]

Hello guys,

I've just pushed some modification, and I added annotation support that introduce 'true' DI support.

For the moment the implementation is broken due to bugs in scalabeans (scala reflection library), so I put it in comments (the annotation is here btw).

[you can view this code in the Annotable trait here: https://github.com/aloiscochard/sdi/blob/master/src/main/scala/sdi/injector.scala]

This feature will enable to inject field without dependency on the injector, but there is some restriction with it's (future) usage:

- can't inject on constructor

- can be only used on mutable field

Next to that I've updated the module/application example to show how mock can be used, by using inject in constructor:

https://github.com/aloiscochard/sdi/blob/master/src/test/scala/sdi/examples/1_Module.scala

I'm sure that the mix of service locator/DI will provide a good flexibility, but I don't want to support annotation on constructor. This will break the idiom behind what I already created (and the functional power of it).

Then about using multiple instance with injector dependency:

You can do it (as dholbrook) the same way you do it in Guice, simply implement Context on a class instead of on object (singleton) and use it as parameter to your module, I'll add an example (or update the module one) for this during the week-end.

And finally about configuration file:

I agree it's not needed for compile time (using DSL is really smart), but this could be really cool if one can map directly some user configuration to the binding directly. I'll try to create basic component for this this week-end too.

I'm a bit in rush right now (spend night hacking), and can't elaborate more.

I really appreciate your efforts and interests, I'm sure this framework can achieve a really versatile way of doing decoupling in Scala, but I apologize for the lack of documentation and explanation I did initially.

Thanks a lot,

[Alois Cochard]

On 26 May 2011 23:35, Przemyslaw Pokrywka <przemysla...@gmail.com> wrote:

Hi,

While I find the project quite interresting, its Service Locator nature is clearly a disadvantage.

I doubt whether SDI allows you to have several instances of a component configured differently at the same time. Please correct me, if I'm wrong.

Say I would need several UserServices, each with different Repository. Should I call childify multiple times?

I've just had time to code you a sample, didn't tested it (sure it work), but I gonna update the example to reflect this idiom:

http://pastie.org/1979842

So now after have saw all the different way of using it, you must feel the flexibility of this library.

But I must define guideline (an idiomatic way of using it) to make people use it correctly (and first of all well designed examples)... because with this framework, like with scala:

http://www.popartuk.com/g/l/lgppr40105+great-power-great-responsibility-spiderman-art-print.jpg

I let you imagine how cool this could be if you override binding of SDI-enabled libraries.

 

Scala *is* different than Java in many areas, though problems of inproper DI are still relevant in this language. One of Service Locator's basic weaknesses is that it is shared by multiple components, that prevents them to be configured in a different way.

I'm waiting for that constructor parameter approach you've mentioned.

regards,

Przemek