Re: [lsug] Dependency Injection

From: Alois C.
Sent on: Thursday, February 14, 2013 9:44 PM



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

Hi Alois,

 

thanks for elaborating. I'd love to find some spare time and give Sindi a shot on one of the previous projects. Might take some time though... :(

 

Re reflection & structured types:

is this still the case in Scala 2.10? Didn't dig into compiler details, but I'm wondering why the scala compiler needs to create reflection code to implement structure types? Given the pace of optimizations I wouldn't be surprised if this particular concern is already obsolete.


Very good question, I'm not sure about that, but iirc it really depend of how the structural type is used. Maybe someone else would have the answer, Kevin?

 

Re compile-time vs runtime-binding:

I agree, a large part of each application I ever dealt with can easily be assembled statically. In fact - leaving an aspect-stuff like transaction management aside - you'd even don't need a DI container for it, a single factorymethod

Well, with a single factory-method you'll end with lot of boilerplate to deal with choosing a specific implementation according to a configuration settings.

With sindi-core + sindi-config, it become quite easy, you just pattern match on your configuration value and choose the implementation (I plan to add some helper to be able to that with even less boilerplate).

But this is suited only when you know in advance all the possible implementations. 

would be sufficient. Regarding my mentioned scenario though, I'd need runtime binding as we bundle different message client implementations depending on the target platforms messaging product - how would Sindi help?

 


For this kind of scenario (where you don't know in advance the implementation), I think the best approach is to use the "Plugin" feature of Sindi which use behind the scene the Java ServiceLocator:

Obviously you loose the safety for this specific binding, as it become a purely runtime based (classpath), but as sindi return a List in this case you can add a failover strategy or have a default implementation and print a warning.
 

tx,


Cheers :) 

Erich

 

From: [address removed] [mailto:[address removed]] On Behalf Of Alois Cochard
Sent: 14 February[masked]:04


To: [address removed]
Subject: Re: [lsug] Dependency Injection

 

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[masked]: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[masked]: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,[masked]: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[masked]: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 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

  • apply(Scala)

    Use promocode LSUGAppliesScala for €75 discount on the €200 Early Bird

  • _.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