addressalign-toparrow-leftarrow-rightbackbellblockcalendarcameraccwchatcheckchevron-downchevron-leftchevron-rightchevron-small-downchevron-small-leftchevron-small-rightchevron-small-upchevron-upcircle-with-checkcircle-with-crosscircle-with-pluscrosseditemptyheartexportfacebookfolderfullheartglobegmailgoogleimageimagesinstagramlinklocation-pinmagnifying-glassmailminusmoremuplabelShape 3 + Rectangle 1outlookpersonplusprice-ribbonImported LayersImported LayersImported Layersshieldstartickettrashtriangle-downtriangle-uptwitteruseryahoo

RE: [lsug] Dependency Injection

From: Erich E.
Sent on: Friday, February 15, 2013 3:34 PM

I feel honored that you felt the need to google me. I apologize, though I didn't feel it necessary. I believe I very clearly stated "spring or any other container" so it was quite clearly "DI container yes or no". My opions are entirely my own (as my boss can tell) and while I certainly have the most experience with Spring, I am usually much more interested in fundamental questions and answers rather particular technologies. Alois seems to have understood that quite well, I very much hope you will too.

 

Re implicits, yes I have used them all. And I am happy to hear it works for you. Within my team we felt them to be a burdern and a dangerous path for the evolution of the codebase.

 

cheers,

Erich

 

From: [address removed] [mailto:[address removed]] On Behalf Of Kevin Wright
Sent: 15 February[masked]:59
To: [address removed]
Subject: Re: [lsug] Dependency Injection

 

In the interests of transparency, I feel that Erich should have a disclaimer that he's an ex-employee of SpringSource and now works with a consultancy that heavily pushes their Spring expertise.  So he *may* have a biased opinion here :)

 

 

implicits are NOT evil.

 

Ever mapped over a List and expected the output to be of type List?

or a BitSet and expected to get a Set back?

or invoked .sum on a collection of *any* type?

or used JavaConverters?

 

These are all good examples of things that simply wouldn't be possible without implicits, and they're all Good Things(™) and perfectly safe.

 

Ever used used scala.concurrent.Future or akka.util.Future?  Then you're also using implicits to pass on the ExecutionContext.  It's *classic* type-based auto wiring/dependency injection and is perfectly safe.

 

 

There are examples of implicit usage that aren't good...  JavaConverters is far from perfect, and any2stringadd is positively evil.  This isn't an inherent problem with implicits, it's just a problem with certain patterns of implementation.

 

 

I can state with 100% confidence that we've happily been using implicits for wiring within Zeebox without any problem whatsoever; and that we do so in a system roughly 2 years old with 100s of components and contributed to by over 50 engineers.

 

 

On 14 February[masked]:26, Erich Eichinger <[address removed]> wrote:

@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



 

--





--
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]





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

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



 

--
Kevin Wright
mail: [address removed]
gtalk / msn : [address removed]

vibe / skype: kev.lee.wright

steam: kev_lee_wright

 

"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra





--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
This message was sent by Kevin Wright ([address removed]) from London Scala Users' Group.
To learn more about Kevin Wright, 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

  • 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