RE: [lsug] Dependency Injection

From: Erich E.
Sent on: Thursday, February 14, 2013 8:26 PM

@Alois,

 

From my experience, implicits are probably the biggest evil in Scala (as long as your not implementing a DSL). Their use made our codebase hard to discover and hence maintain over time. One simply doesn't know after a while where the particular implicit comes from. To me, it smells quite strong like the good old java classpath/class replacement trick. This experience makes me very curious, how you got this to work for you in a project that involves a larger team and goes over at least 1-2 years of development?

 

-Erich

 

From: [address removed] [mailto:[address removed]] On Behalf Of Alois Cochard
Sent: 14 February[masked]:56
To: [address removed]
Subject: Re: [lsug] Dependency Injection

 

Hi Ryan :)

 

First about the fallacies of default argument, let's take a simple example:

 

class Bar

class FooA(bar: Bar = new Bar)

class FooB(bar: Bar = new Bar)

 

Here the issue is obvious: Bar won't be a singleton!

 

So one could say, well I'll do it like that:

 

object Bar extends BarLike

trait BarLike

class FooA(bar: BarLike = Bar)

class FooB(bar: BarLike = Bar)

 

And now the issue: If you want to substitute BarLike implementation, you'll have to give explicitly to every type that use it

 

Then about the second point, implicits are very flexible and can be used in many different way, but I'll show a very simple example:

class Bar

object Bar {

   implicit val bar = new Bar

}

class FooA(implicit bar: Bar)

class FooB(implicit bar: Bar)

 

Here you go, now you can instantiate FooA/B without giving bar explicitly, it will be find implicitly in the companion object, but if you set an other implicit Bar in scope where FooA/B are instantiated, it will have priority over the one in the companion :)

 

Hope that help,

 

Alois

 

 

On 14 February[masked]:40, Ryan LeCompte <[address removed]> wrote:

Can you give an example of your "implicitly only" lightweight approach? It sounds very compelling. Also, what's wrong with a simple approach where your dependencies are concrete constructor parameters (not implicit), but they have default values to make the construction easier on the user? This is what we use in the Ruby world and it works well. :-)

 

Ryan


On Feb 14, 2013, at 8:31 AM, Alois Cochard <[address removed]> wrote:

Hi Sandro,

 

Thanks for your interest :)

 

As I said in my original message the website is outdated and refer to sindi 0.5 which was using a compiler plugin (current version is 1.0-RC3 and is implemented with implicits), I should update it but haven't found time yet to do so :-s

 

I plan to add a simple app example, as test don't really show how to integrate it concretely in an application, the approach I generally take:

 

class Bar

class Foo(bar: Bar) {

   def run = println("hello world")

}

 

trait ApplicationContext {

   implicit val bar = bind(new Bar) // manually creating instance

   implicit val foo = bind(autowire[Foo]) // using autowiring to inject construtor parameter

}

 

object App extends ApplicationContext {

   inject[Foo].run

}

 

Hope that help getting started ;)

 

Cheers

 

 

On 14 February[masked]:16, Sandro Mancuso <[address removed]> wrote:

Hi Alois

 

Thanks for your email. 

 

I'm having problems to look at the documentation / examples: http://aloiscochard.github.com/sindi/guide/basic.html

 

 

I'm also getting a 404 when looking at the examples: https://github.com/aloiscochard/sindi/wiki/Examples

 

 

I'll definitely have a closer look at it soon. 

 

Many thanks and good luck with the project. 


From: Alois Cochard <[address removed]>
To: [address removed]
Sent: Thursday, 14 February 2013, 15:59


Subject: Re: [lsug] Dependency Injection

 

Hi Sandro,

 

You might be interested in http://github.com/aloiscochard/sindi

 

Which I am the auther, doc on the website aren't updated for last version but there is some nice tests: 

 

Sindi isn't intrusive, and guarantee your types to be bound at compile time vs runtime thanks to implicitis resolution, and using autowiring (that use macro in 2.10) you can avoid good bunch of boilerplates.

 

I'm a bit skeptic about cake pattern in large project as this introduce a good bunch of complexity with path dependent type, even if some technic shown recently by Daniel Spiewak and Debasish Gosh that use existential type enable to work around issue introduced by path dependent type, I still find it very boilerplaty

 

For small scale project cake/reader monad might be well suited.

 

In one of my personal project I started recently I try to do it using implicits without even using Sindi, I'm not sure it will scale well outside of utilities libraries... time will tell ;)

 

May the Force be with you,

 

Alois Cochard

 

 

On 14 February[masked]:51, Sandro Mancuso <[address removed]> wrote:

Hi all

We are starting a project with Scala but none of us are very experienced with it. 

We were looking for ways to do dependency injection and we found the following:

Cake pattern: 
http://www.cakesolutions.net/teamblogs/2011/12/15/dependency-injection-vs-cake-pattern/


SubCut:


https://github.com/dickwall/subcut/blob/master/GettingStarted.md
http://vimeo.com/36217414

We also find a few dead repositories on github but nothing very relevant. 

I was wondering what you guys are using of DI in Scala. Pros and Cons?

Maybe because of my lack of experience in Scala, I found the Cake Pattern a bit verbose and SubCut a bit intrusive since I need to add SubCut stuff to all my classes. At least, that was my impression when reading the tutorial. 

Any views?

Thanks

 

Sandro Mancuso
Founder of the
London Software Craftsmanship Community

Blog:




--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])

This message was sent by Ryan LeCompte ([address removed]) from London Scala Users' Group.
To learn more about Ryan LeCompte, visit his/her member profile



 

--

Alois Cochard





--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
This message was sent by Alois Cochard ([address removed]) from London Scala Users' Group.
To learn more about Alois Cochard, visit his/her member profile
Set my mailing list to email me As they are sent | In one daily email | Don't send me mailing list messages

Meetup, POB 4668 #37895 NY NY USA 10163 | [address removed]

Our Sponsors

  • Scala Dojo

    Web site for monthly Scala Dojo

  • Scala Jobs

    Google Group of Scala Jobs in the London Area

  • _.underscore

    Scala consultants, trainers, and developers, based in London, UK

  • Springer

    Help and supporters of the monthly dojo

  • Mind Candy

    Help with the Adv Scala Meet-up

  • Skills Matter

    Provide the venue for many of our meetings.

People in this
Meetup are also in:

Sign up

Meetup members, Log in

By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy