Re: [lsug] Dependency Injection

From: Alois Cochard
Sent on: Thursday, February 14, 2013 9:03 PM
Hi Erich,

1. About implicits being the biggest evil, I would say that when working with a big team of developers of different skills, it might be better to keep implicits constrained in libraries. Then developer more experienced will create and extend libraries that less skilled developer will then use... but saying there are probably the biggest evil is very extreme, and you might better enjoy language like Kotlin then ;)

2. About performance issue of reflection, I think it's something to not underestimate, without of course going to the premature optimization side of the Force. I think serialization is a great example where avoiding reflection can be really interesting, of course most library that use reflection tend to cache it, but if you can avoid it why not!? You can find some good example of that in recent Miles Sabin work with Blueeyse integration with Shapeless or my experiment here https://github.com/aloiscochard/sherpa.

I think it's pretty obvious for anyone that not only rendering software at Disney have to care about good serialization performance ;)

And finally about DI, cake/implicits, I think you missed my point, why do you think I created Sindi?

If I thought cake/implicits was well suited for large scale project I would never have created such library, but if you look at it in detail you will realize something:

Sindi give you all what you want in term of DI (different configuration per environments, nice way to modularize your application context and split it by domain, ...).

Then you argue about why using it in favor of Spring which is proved to be mature:
Spring doesn't verify binding at compile-time but only at runtime, it's a bit like comparing the usage of null vs Option, and I'm pretty sure that as an exprienced scala coder you realize the gain of safety when using Option over null!

Sindi give you the best of both worlds, because you can use it like Spring to have an easy to read definition of binding (which scale and is composable), but at the same time you have the same safety as if you where using implicits or cake :)

My point was that for small project, implicits/cake can be enough, but I definitely agree that cake might be tricky to scale, specially with the "Bakery of Doom" of path dependent type.

Cheers

Alois



On 14 February 2013 21:36, Erich Eichinger <[address removed]> wrote:

> Be careful with structural type, when used for bindings it's probably fine, but one should keep in mind they can generate some slow runtime reflection.

 

that's something you'd probably deal with once you *really* hit a performance problem - after carefully measuring. And I bet my left arm (I'm left-handed), unless you're writing software rendering the next Disney animation or a high-performance trading agent, you'll find your problem to be elsewhere

 

> I don't get the idea of using spring scala when starting a project from scratch?

> You can use spring libraries without necessary the spring DI

 

Why not? Or better: why not any of the DI containers out there? No matter whether you use Spring or anything else, they are mature and provide a lot more than just plain DI like transaction management.

 

How do you - for instance - achieve different endpoint configurations or -types for different environments? Be it different datastores, messaging technologies, etc. ? Eg I'm working on products that need to plug into different messaging services - how would you solve this with cake or implicits?

 

tx,

Erich

 

 

From: [address removed] [mailto:[address removed]] On Behalf Of Alois Cochard
Sent: 14 February 2013 18:34
To: [address removed]
Subject: RE: [lsug] Dependency Injection

 

Be careful with structural type, when used for bindings it's probably fine, but one should keep in mind they can generate some slow runtime reflection.

I don't get the idea of using spring scala when starting a project from scratch?

You can use spring libraries without necessary the spring DI

On Feb 14, 2013 6:18 PM, "Erich Eichinger" <[address removed]> wrote:

first of all, ideally the DI container you are using shouldn't affect your class design at all. Its only job is to assemble your components.

 

I have used the cake pattern in a medium-sized application and have to admit I still got mixed feelings about it.

 

Alternative thought: To reduce the number of types in Scala you can also make use of functions and/or structured types for your injection needs. This is what I ended up making lots of use of, it makes unit testing very easy - no mocking needed, since all you pass in as dependencies are callback functions.

 

I know (but never used it myself) that Jan Machacek has done quite some work on using Spring to assemble your Scala components, see e.g. http://skillsmatter.com/podcast/scala/spring-scala

 

hth,

Erich

 

From: [address removed] [mailto:[address removed]] On Behalf Of Noel Kennedy


Sent: 14 February 2013 17:21
To: [address removed]
Subject: Re: [lsug] Dependency Injection

 

We use the cake pattern after a brief fling with just using abstract fields.  

 

I have run into the path dependent type problem a few times since we refactored to using cake.  Briefly our problem was caused by trying to share an instance implementing a contract, from one cake inside another cake.  Every time this happened it made me realise I was actually trying to share state and I refactored out an actor or a singleton or whatever and the problem goes away.

 

 

Pick a good naming convention for your traits if you go with cake as you will need it!

 

You can use ours if you like

 

 

trait xxxDependency {

 

trait xxx {} // The unimplemented service contract.

 

def xxxService : xxx

}

 

trait xxx{implementation name}  extends xxxDependency {

 

//self type to all other dependencies

 

trait {implementation name} extends xxx {} //actual implementation of service

}

 

 

 

 

 

cake cons

 

Head scratching to work out how it works

Boiler plate traits

Path dependency type problem discussed above 

 

cake pros

 

Compile time checking of dependencies.  

Everything is wired up in code 

(with an IDE) you can easily follow dependency graphs

One less framework that you need to learn and and fuss over.  

And no xml

 

 

 

Cheers,

 

Noel

 

 

 

 

On 14 Feb 2013, at 15: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

 





--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
This message was sent by Sandro Mancuso ([address removed]) from London Scala Users' Group.
To learn more about Sandro Mancuso, visit his/her member profile
Meetup, POB 4668 #37895 NY NY USA 10163 | [address removed]

 

        

This message, together with any attachments, is intended for the stated addressee(s) only and may contain privileged or confidential information. Any views or opinions presented are solely those of the author and do not necessarily represent those of the Royal Veterinary College (RVC). If you are not the intended recipient, please notify the sender and be advised that you have received this message in error and that any use, dissemination, forwarding, printing, or copying is strictly prohibited. Unless stated expressly in this email, this email does not create, form part of, or vary any contractual or unilateral obligation. Email communication cannot be guaranteed to be secure or error free as information could be intercepted, corrupted, amended, lost, destroyed, incomplete or contain viruses. Therefore, we do not accept liability for any such matters or their consequences. Communication with us by email will be taken as acceptance of the risks inherent in doing so.





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



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

  • Mind Candy

    Help with the Adv Scala Meet-up

  • Skills Matter

    Provide the venue for many of our meetings.

  • Scala Times

    A free, once-weekly Scala news flash

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