Re: [lsug] Dependency Injection

From: Kevin W.
Sent on: Friday, February 15, 2013 3:03 PM


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


add any large social online company to that list.  I deal with neither trading nor animation, but still have to care about performance.  We have to handle tens of thousands of people looking to sign up and use the app within a couple of hours, we care about performance.

So does twitter, and meetup, and foursquare, and linkedin, and… there's a lot of people in this space using Scala :)


 

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


I use built-in language features for injection, a configuration tool for configuration.  Typesafe have quite a good one, Akka uses it: https://github.com/typesafehub/config


 

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



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

Our Sponsors

  • Scala Dojo

    Web site for monthly Scala Dojo

  • Scala Jobs

    Google Group of Scala Jobs in the London Area

  • scala.exchange

    Discount code SCALAX-UG-CODE25 for 25% discount until 1st Aug'15

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