addressalign-toparrow-leftarrow-rightbackbellblockcalendarcameraccwcheckchevron-downchevron-leftchevron-rightchevron-small-downchevron-small-leftchevron-small-rightchevron-small-upchevron-upcircle-with-checkcircle-with-crosscircle-with-pluscontroller-playcrossdots-three-verticaleditemptyheartexporteye-with-lineeyefacebookfolderfullheartglobegmailgooglegroupshelp-with-circleimageimagesinstagramFill 1linklocation-pinm-swarmSearchmailmessagesminusmoremuplabelShape 3 + Rectangle 1ShapeoutlookpersonJoin Group on CardStartprice-ribbonprintShapeShapeShapeShapeImported LayersImported LayersImported Layersshieldstartickettrashtriangle-downtriangle-uptwitteruserwarningyahoo

Re: [lsug] Dependency Injection

From: Alois C.
Sent on: Thursday, February 14, 2013 6:55 PM
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,


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. :-)


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 {

Hope that help getting started ;)


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:

I'm also getting a 404 when looking at the 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

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:


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?

Sandro Mancuso
Founder of the London Software Craftsmanship Community

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

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