Dependency injection in Scala?

[Stepan Koltsov-2]

Hello,

Is there any way to write code in Scala as in Java+Spring? I. e. with
dependency injection of components.

It is hard to write large applications without DI.

Should DI be done in pure Scala some way, or there is any framework,
or Spring itself should be used?

S.

[David Pollak]

See http://onestepback.org/articles/depinj/contents.html

In general, Scala doesn't need DI because one can use type-safe
"creator" functions.

Stepan Koltsov wrote:

> Hello,
>
> Is there any way to write code in Scala as in Java+Spring? I. e. with
> dependency injection of components.
>
> It is hard to write large applications without DI.
>
> Should DI be done in pure Scala some way, or there is any framework,
> or Spring itself should be used?
>
> S.
>  

[Stepan Koltsov-2]

What is "type-safe creator functions"?

S.

On 2/1/08, David Pollak <dpp@...> wrote:

> See http://onestepback.org/articles/depinj/contents.html
>
> In general, Scala doesn't need DI because one can use type-safe
> "creator" functions.
>
> Stepan Koltsov wrote:
> > Hello,
> >
> > Is there any way to write code in Scala as in Java+Spring? I. e. with
> > dependency injection of components.
> >
> > It is hard to write large applications without DI.
> >
> > Should DI be done in pure Scala some way, or there is any framework,
> > or Spring itself should be used?
> >
> > S.
> >
>
>

[David Pollak]

object HttpBuilder {
  var buildHttp: () => HttpThingIntf = new NormalHttpThing
}

// I want to change what is built by the HttpBuilder:

HttpBuilder.buildHttp = () => new MockHttpThing

And to build a new HttpThing:

val myHttpThing = HttpBuilder.buildHttp()

You can extend the paradigm with PartialFunctions:

object HttpBuilder {
  var buildHttp: PartialFunction[Unit, HttpThingIntf] = {
    case _ => new NormalHttpThing
  }
}

And you can modify the functionality with a conditional:

HttpBuilder.buildHttp = {
  case _ if someCondition => new Condition1HttpMock
  case _ if someOtherCondition => new Condition2HttpMock
} orElse HttpBuilder.buildHttp

Stepan Koltsov wrote:

What is "type-safe creator functions"?

S.

On 2/1/08, David Pollak dpp@... wrote:
  

See http://onestepback.org/articles/depinj/contents.html

In general, Scala doesn't need DI because one can use type-safe
"creator" functions.

Stepan Koltsov wrote:
    

Hello,

Is there any way to write code in Scala as in Java+Spring? I. e. with
dependency injection of components.

It is hard to write large applications without DI.

Should DI be done in pure Scala some way, or there is any framework,
or Spring itself should be used?

S.

      

[Alex Boisvert-3]

On 2/1/08, Stepan Koltsov <stepan.koltsov@...> wrote:

Is there any way to write code in Scala as in Java+Spring? I. e. with
dependency injection of components.

It is hard to write large applications without DI.

Should DI be done in pure Scala some way, or there is any framework,
or Spring itself should be used?

Hi Stepan,

I see two sides to this story,
-How to structure code to make it more configurable? (parametric)
-How to wire parts together and provide configuration

Scala's type system and concise syntax help you on both aspects compared to Java.  I've posted a small example yesterday [1].

Similarly to Java and other OO programming languages without open classes, you want to reduce as much as possible static linking inside your application.  This typically implies two practices.  First, using object factories instead of calling constructors directly; and second, minimizing the use of singleton objects.  These practices apply to any part or behavior that you want to be able to reconfigure.  It's okay to rely on static linking for things that you don't expect (or want to) change.   The "Cake Pattern" paper [2] discusses some of these considerations.

In practice, I've found that using Scala scripts (using the interpreter) was a better solution than Spring to wire pieces together and inject configuration parameter inside my applications.   There are some issues with using Spring since Scala conventions for class naming, method naming (JavaBeans-style setters/getters) and overall application structuring tend to differ from Java.  Some simple things work but you'll run into issues with most complex scenarios.   As far as I know, nobody has tried to resolve these issues or is working on a Scala dependency-injection framework.

Hope this helps,
alex

[1] http://www.nabble.com/Cake-pattern-and-dependency-injection-td15199303.html#a15208024
[2] http://lamp.epfl.ch/~odersky/papers/ScalableComponent.pdf

[Matt Hellige]

I agree with other replies, but in a more guarded way. I think the
need for a DI framework is somewhat reduced in Scala, as compared to
Java. But I definitely don't believe that the need is completely
eliminated. There are many things that Spring does that are not easy
to achieve without a framework. So I do advise that you look into the
patterns that people mentioned, but I also expect that people will
continue to use Spring/Guice/etc. with Scala and that eventually we
will see a new approach to DI that is a more natural fit with Scala's
naming conventions and language features.

Matt

On Feb 1, 2008 11:28 AM, Alex Boisvert <boisvert@...> wrote:

>
> On 2/1/08, Stepan Koltsov <stepan.koltsov@...> wrote:
>
>
> > Is there any way to write code in Scala as in Java+Spring? I. e. with
> > dependency injection of components.
> >
> > It is hard to write large applications without DI.
> >
> > Should DI be done in pure Scala some way, or there is any framework,
> > or Spring itself should be used?
>
> Hi Stepan,
>
> I see two sides to this story,
> -How to structure code to make it more configurable? (parametric)
> -How to wire parts together and provide configuration
>
> Scala's type system and concise syntax help you on both aspects compared to
> Java.  I've posted a small example yesterday [1].
>
> Similarly to Java and other OO programming languages without open classes,
> you want to reduce as much as possible static linking inside your
> application.  This typically implies two practices.  First, using object
> factories instead of calling constructors directly; and second, minimizing
> the use of singleton objects.  These practices apply to any part or behavior
> that you want to be able to reconfigure.  It's okay to rely on static
> linking for things that you don't expect (or want to) change.   The "Cake
> Pattern" paper [2] discusses some of these considerations.
>
> In practice, I've found that using Scala scripts (using the interpreter) was
> a better solution than Spring to wire pieces together and inject
> configuration parameter inside my applications.   There are some issues with
> using Spring since Scala conventions for class naming, method naming
> (JavaBeans-style setters/getters) and overall application structuring tend
> to differ from Java.  Some simple things work but you'll run into issues
> with most complex scenarios.   As far as I know, nobody has tried to resolve
> these issues or is working on a Scala dependency-injection framework.
>
> Hope this helps,
> alex
>
> [1]
> http://www.nabble.com/Cake-pattern-and-dependency-injection-td15199303.html#a15208024
>  [2] http://lamp.epfl.ch/~odersky/papers/ScalableComponent.pdf

--
Matt Hellige / matt@...
http://matt.immute.net

[Jamie Webb-2]

On 2008-02-01 19:18:53 Stepan Koltsov wrote:
> Hello,
>
> Is there any way to write code in Scala as in Java+Spring? I. e. with
> dependency injection of components.
>
> It is hard to write large applications without DI.
>
> Should DI be done in pure Scala some way, or there is any framework,
> or Spring itself should be used?

The code below (using the example from David's link) is a way to very
closely model Spring-style autowiring using pure, immutable, type-safe
Scala. I should say that I'm not necessarily recommending this style;
there are a great many ways to skin this cat. For example the Cake
pattern uses mixins to combine all the components into a single
namespace.

First define the services, exactly as usual:

  trait OnOffDevice {
      def on() : Unit
      def off() : Unit
  }
 
  trait SensorDevice {
      def isCoffeePresent : Boolean
  }
 
  class Heater extends OnOffDevice {
      def on() {}
      def off() {}
  }
 
  class PotSensor extends SensorDevice {
      def isCoffeePresent = true
  }

Now the consumer. The dependencies are defined as a nested trait with
an abstract instance. You could import it if you like, to avoid
writing env.foo each time.

  abstract class Warmer {
      trait Env {
          val potSensor : SensorDevice
          val heater : OnOffDevice
      }
      protected val env : Env
 
      def trigger() {
          if(env.potSensor.isCoffeePresent) env.heater.on()
          else env.heater.off()
      }
  }

To build a configuration, we instantiate the objects:

  val thePotSensor = new PotSensor
  val theHeater = new Heater
  val theWarmer = new Warmer { protected val env = new Config with Env }

And name them, so that they will be wired together:

  class Config {
      lazy val potSensor = thePotSensor
      lazy val heater = theHeater
  }

The trick is the 'new Config with Env', which allows us to take a
single global Config class, and make it implement whatever Env each
component requests. That's the bit you can't do in Java. Another
possibility would be to use structural subtyping, which would save a
few keystrokes for a slight performance hit.

/J

[Raoul Duke]

The D.I. threads are all very interesting and I hope to understand it
some day :-)

I hope that some day somebody who groks it all can make a wiki page
which gives an overview of the alternative skinnings and trade-offs;
while Scala really can be unapproachable for a Java person, things
like these threads where the new ideas and approaches of Scala are
motivated by very common/core Java tasks are what will give Java folks
reason to grow. Thanks to everybody who made Scala and who is
explaining it.

sincerely.

On Feb 1, 2008 10:03 AM, Jamie Webb <j@...> wrote:

> On 2008-02-01 19:18:53 Stepan Koltsov wrote:
> > Hello,
> >
> > Is there any way to write code in Scala as in Java+Spring? I. e. with
> > dependency injection of components.
> >
> > It is hard to write large applications without DI.
> >
> > Should DI be done in pure Scala some way, or there is any framework,
> > or Spring itself should be used?
>
> The code below (using the example from David's link) is a way to very
> closely model Spring-style autowiring using pure, immutable, type-safe
> Scala. I should say that I'm not necessarily recommending this style;
> there are a great many ways to skin this cat. For example the Cake
> pattern uses mixins to combine all the components into a single
> namespace.
>
> First define the services, exactly as usual:
>
>   trait OnOffDevice {
>       def on() : Unit
>       def off() : Unit
>   }
>
>   trait SensorDevice {
>       def isCoffeePresent : Boolean
>   }
>
>   class Heater extends OnOffDevice {
>       def on() {}
>       def off() {}
>   }
>
>   class PotSensor extends SensorDevice {
>       def isCoffeePresent = true
>   }
>
> Now the consumer. The dependencies are defined as a nested trait with
> an abstract instance. You could import it if you like, to avoid
> writing env.foo each time.
>
>   abstract class Warmer {
>       trait Env {
>           val potSensor : SensorDevice
>           val heater : OnOffDevice
>       }
>       protected val env : Env
>
>       def trigger() {
>           if(env.potSensor.isCoffeePresent) env.heater.on()
>           else env.heater.off()
>       }
>   }
>
> To build a configuration, we instantiate the objects:
>
>   val thePotSensor = new PotSensor
>   val theHeater = new Heater
>   val theWarmer = new Warmer { protected val env = new Config with Env }
>
> And name them, so that they will be wired together:
>
>   class Config {
>       lazy val potSensor = thePotSensor
>       lazy val heater = theHeater
>   }
>
> The trick is the 'new Config with Env', which allows us to take a
> single global Config class, and make it implement whatever Env each
> component requests. That's the bit you can't do in Java. Another
> possibility would be to use structural subtyping, which would save a
> few keystrokes for a slight performance hit.
>
> /J
>

[Alex Boisvert-3]

Hi Matt,

I agree with you Scala by itself (as it is today) it's not an ideal solution, but from my experience it beats using Spring/Guice.  The main advantages I see are,

1) No "impedance mismatch" between Java and Scala idioms; you can integrate code that follows different dependency-injection approaches
    (constructor-injection, setter-injection, service lookup, ..., cake pattern, mix of Java and Scala)
2) Stronger typing (no XML or annotations)
3) No additional framework to learn
4) You have the full power of Scala at your disposal so you have more options for the structuring of configuration itself

I'm also hopeful that the situation will improve with additional language support such as virtual classes, first-class properties, ideas from Sean McDirmid's SuperGlue language, etc.

alex

On 2/1/08, Matt Hellige <matt@...> wrote:

I agree with other replies, but in a more guarded way. I think the
need for a DI framework is somewhat reduced in Scala, as compared to
Java. But I definitely don't believe that the need is completely
eliminated. There are many things that Spring does that are not easy
to achieve without a framework. So I do advise that you look into the
patterns that people mentioned, but I also expect that people will
continue to use Spring/Guice/etc. with Scala and that eventually we
will see a new approach to DI that is a more natural fit with Scala's
naming conventions and language features.

Matt

On Feb 1, 2008 11:28 AM, Alex Boisvert <boisvert@...> wrote:
>
> On 2/1/08, Stepan Koltsov <stepan.koltsov@...> wrote:
>
>
> > Is there any way to write code in Scala as in Java+Spring? I. e. with
> > dependency injection of components.
> >
> > It is hard to write large applications without DI.
> >
> > Should DI be done in pure Scala some way, or there is any framework,
> > or Spring itself should be used?
>
> Hi Stepan,
>
> I see two sides to this story,
> -How to structure code to make it more configurable? (parametric)
> -How to wire parts together and provide configuration
>
> Scala's type system and concise syntax help you on both aspects compared to
> Java.  I've posted a small example yesterday [1].
>
> Similarly to Java and other OO programming languages without open classes,
> you want to reduce as much as possible static linking inside your
> application.  This typically implies two practices.  First, using object
> factories instead of calling constructors directly; and second, minimizing
> the use of singleton objects.  These practices apply to any part or behavior
> that you want to be able to reconfigure.  It's okay to rely on static
> linking for things that you don't expect (or want to) change.   The "Cake
> Pattern" paper [2] discusses some of these considerations.
>
> In practice, I've found that using Scala scripts (using the interpreter) was
> a better solution than Spring to wire pieces together and inject
> configuration parameter inside my applications.   There are some issues with
> using Spring since Scala conventions for class naming, method naming
> (JavaBeans-style setters/getters) and overall application structuring tend
> to differ from Java.  Some simple things work but you'll run into issues
> with most complex scenarios.   As far as I know, nobody has tried to resolve
> these issues or is working on a Scala dependency-injection framework.
>
> Hope this helps,
> alex
>
> [1]
> http://www.nabble.com/Cake-pattern-and-dependency-injection-td15199303.html#a15208024
>  [2] http://lamp.epfl.ch/~odersky/papers/ScalableComponent.pdf



--
Matt Hellige / matt@...
http://matt.immute.net

[Erkki Lindpere-2]

You are talking about directly calling "bean" setters/constructors etc.
from a scala script instead of configuring the relationships?

Doesn't that eliminate a lot of useful functionality that Spring offers?
For example, in Spring I can configure that some beans are created for
each web request, while some are singletons. How would you do that in a
Scala script? having multiple scripts is one way I guess.

But IMHO, it's important that in Spring you can create a
*configuration*, of which there can be different instances.

Perhaps this could be done easily with some DSL in Scala that is type
safe, but creates a configuration instead of manipulating the objects
immediately...

Erkki

Alex Boisvert wrote:

> Hi Matt,
>
> I agree with you Scala by itself (as it is today) it's not an ideal
> solution, but from my experience it beats using Spring/Guice.  The
> main advantages I see are,
>
> 1) No "impedance mismatch" between Java and Scala idioms; you can
> integrate code that follows different dependency-injection approaches
>     (constructor-injection, setter-injection, service lookup, ...,
> cake pattern, mix of Java and Scala)
> 2) Stronger typing (no XML or annotations)
> 3) No additional framework to learn
> 4) You have the full power of Scala at your disposal so you have more
> options for the structuring of configuration itself
>
> I'm also hopeful that the situation will improve with additional
> language support such as virtual classes, first-class properties,
> ideas from Sean McDirmid's SuperGlue language, etc.
>
> alex
>
>
> On 2/1/08, *Matt Hellige* <matt@... <mailto:matt@...>>
> wrote:
>
>     I agree with other replies, but in a more guarded way. I think the
>     need for a DI framework is somewhat reduced in Scala, as compared to
>     Java. But I definitely don't believe that the need is completely
>     eliminated. There are many things that Spring does that are not easy
>     to achieve without a framework. So I do advise that you look into the
>     patterns that people mentioned, but I also expect that people will
>     continue to use Spring/Guice/etc. with Scala and that eventually we
>     will see a new approach to DI that is a more natural fit with Scala's
>     naming conventions and language features.
>
>     Matt
>
>     On Feb 1, 2008 11:28 AM, Alex Boisvert <boisvert@...
>     <mailto:boisvert@...>> wrote:
>     >
>     > On 2/1/08, Stepan Koltsov <stepan.koltsov@...
>     <mailto:stepan.koltsov@...>> wrote:
>     >
>     >
>     > > Is there any way to write code in Scala as in Java+Spring? I.
>     e. with
>     > > dependency injection of components.
>     > >
>     > > It is hard to write large applications without DI.
>     > >
>     > > Should DI be done in pure Scala some way, or there is any
>     framework,
>     > > or Spring itself should be used?
>     >
>     > Hi Stepan,
>     >
>     > I see two sides to this story,
>     > -How to structure code to make it more configurable? (parametric)
>     > -How to wire parts together and provide configuration
>     >
>     > Scala's type system and concise syntax help you on both aspects
>     compared to
>     > Java.  I've posted a small example yesterday [1].
>     >
>     > Similarly to Java and other OO programming languages without
>     open classes,
>     > you want to reduce as much as possible static linking inside your
>     > application.  This typically implies two practices.  First,
>     using object
>     > factories instead of calling constructors directly; and second,
>     minimizing
>     > the use of singleton objects.  These practices apply to any part
>     or behavior
>     > that you want to be able to reconfigure.  It's okay to rely on
>     static
>     > linking for things that you don't expect (or want to) change.  
>     The "Cake
>     > Pattern" paper [2] discusses some of these considerations.
>     >
>     > In practice, I've found that using Scala scripts (using the
>     interpreter) was
>     > a better solution than Spring to wire pieces together and inject
>     > configuration parameter inside my applications.   There are some
>     issues with
>     > using Spring since Scala conventions for class naming, method naming
>     > (JavaBeans-style setters/getters) and overall application
>     structuring tend
>     > to differ from Java.  Some simple things work but you'll run
>     into issues
>     > with most complex scenarios.   As far as I know, nobody has
>     tried to resolve
>     > these issues or is working on a Scala dependency-injection
>     framework.
>     >
>     > Hope this helps,
>     > alex
>     >
>     > [1]
>     >
>     http://www.nabble.com/Cake-pattern-and-dependency-injection-td15199303.html#a15208024
>     >  [2] http://lamp.epfl.ch/~odersky/papers/ScalableComponent.pdf
>     <http://lamp.epfl.ch/%7Eodersky/papers/ScalableComponent.pdf>
>
>
>
>     --
>     Matt Hellige / matt@... <mailto:matt@...>
>     http://matt.immute.net
>
>

[Alex Boisvert-3]

On 2/1/08, Erkki Lindpere <erkki@...> wrote:

You are talking about directly calling "bean" setters/constructors etc.
from a scala script instead of configuring the relationships?

Yes, if that's the way the code was written.  (It wouldn't write it like that if I were to write it from scratch; I'd most likely use abstract members)

Doesn't that eliminate a lot of useful functionality that Spring offers?
For example, in Spring I can configure that some beans are created for
each web request, while some are singletons. How would you do that in a
Scala script? having multiple scripts is one way I guess.

In this case you have a Spring interceptor that dispatches requests based on some Spring context configuration.

So you have at least 2 alternatives, 1) use the same Spring interceptor and configure its context using Scala, or 2) write your own Scala interceptor that's configured via Scala scripts.

But IMHO, it's important that in Spring you can create a
*configuration*, of which there can be different instances.

Yes, that's also easy to do.  Your configuration can be a class (or set of classes) and you can instantiate it/them as many times as you want.

Perhaps this could be done easily with some DSL in Scala that is type
safe, but creates a configuration instead of manipulating the objects
immediately...

Yes, most likely if you do this kind of configuration often you would end up with some sort of Scala-based DSL.

alex

[Germán Buela]

Hi Alex,
Regarding the example you posted with a Unix scala script to wire
things together... I have 2 questions:
1) You say this way you can keep the wiring out of application code:
is it a desirable goal to keep it outside of the deployable package
(WAR)? I'm used to having a Spring XML file as part of the project and
I like to simply deliver the WAR for deployment, and everything should
work. How do you handle the script? Do you set it up the first time
only, documenting it as a requirement, and then just deliver a WAR?
2) Noting that the script is OS specific, how would you handle it in
an environment where developers work on a given OS (ie Windows) but
the servers are a different one (ie Solaris)? I suppose developers
would have an alternative version of the script, but if there are
changes it can get tricky...

Thanks

[David Bernard-3]

Hi Alex,

How do you use the script approach in a context (like a webapp) where the script isn't the main ?
How do you use scala as embedded script engine?

/davidB

Alex Boisvert wrote:

> Hi Matt,
>
> I agree with you Scala by itself (as it is today) it's not an ideal
> solution, but from my experience it beats using Spring/Guice.  The main
> advantages I see are,
>
> 1) No "impedance mismatch" between Java and Scala idioms; you can
> integrate code that follows different dependency-injection approaches
>     (constructor-injection, setter-injection, service lookup, ..., cake
> pattern, mix of Java and Scala)
> 2) Stronger typing (no XML or annotations)
> 3) No additional framework to learn
> 4) You have the full power of Scala at your disposal so you have more
> options for the structuring of configuration itself
>
> I'm also hopeful that the situation will improve with additional
> language support such as virtual classes, first-class properties, ideas
> from Sean McDirmid's SuperGlue language, etc.
>
> alex
>
>
> On 2/1/08, *Matt Hellige* <matt@... <mailto:matt@...>> wrote:
>
>     I agree with other replies, but in a more guarded way. I think the
>     need for a DI framework is somewhat reduced in Scala, as compared to
>     Java. But I definitely don't believe that the need is completely
>     eliminated. There are many things that Spring does that are not easy
>     to achieve without a framework. So I do advise that you look into the
>     patterns that people mentioned, but I also expect that people will
>     continue to use Spring/Guice/etc. with Scala and that eventually we
>     will see a new approach to DI that is a more natural fit with Scala's
>     naming conventions and language features.
>
>     Matt
>
>     On Feb 1, 2008 11:28 AM, Alex Boisvert <boisvert@...
>     <mailto:boisvert@...>> wrote:
>      >
>      > On 2/1/08, Stepan Koltsov <stepan.koltsov@...
>     <mailto:stepan.koltsov@...>> wrote:
>      >
>      >
>      > > Is there any way to write code in Scala as in Java+Spring? I.
>     e. with
>      > > dependency injection of components.
>      > >
>      > > It is hard to write large applications without DI.
>      > >
>      > > Should DI be done in pure Scala some way, or there is any
>     framework,
>      > > or Spring itself should be used?
>      >
>      > Hi Stepan,
>      >
>      > I see two sides to this story,
>      > -How to structure code to make it more configurable? (parametric)
>      > -How to wire parts together and provide configuration
>      >
>      > Scala's type system and concise syntax help you on both aspects
>     compared to
>      > Java.  I've posted a small example yesterday [1].
>      >
>      > Similarly to Java and other OO programming languages without open
>     classes,
>      > you want to reduce as much as possible static linking inside your
>      > application.  This typically implies two practices.  First, using
>     object
>      > factories instead of calling constructors directly; and second,
>     minimizing
>      > the use of singleton objects.  These practices apply to any part
>     or behavior
>      > that you want to be able to reconfigure.  It's okay to rely on static
>      > linking for things that you don't expect (or want to) change.  
>     The "Cake
>      > Pattern" paper [2] discusses some of these considerations.
>      >
>      > In practice, I've found that using Scala scripts (using the
>     interpreter) was
>      > a better solution than Spring to wire pieces together and inject
>      > configuration parameter inside my applications.   There are some
>     issues with
>      > using Spring since Scala conventions for class naming, method naming
>      > (JavaBeans-style setters/getters) and overall application
>     structuring tend
>      > to differ from Java.  Some simple things work but you'll run into
>     issues
>      > with most complex scenarios.   As far as I know, nobody has tried
>     to resolve
>      > these issues or is working on a Scala dependency-injection framework.
>      >
>      > Hope this helps,
>      > alex
>      >
>      > [1]
>      >
>     http://www.nabble.com/Cake-pattern-and-dependency-injection-td15199303.html#a15208024
>      >  [2] http://lamp.epfl.ch/~odersky/papers/ScalableComponent.pdf
>
>
>
>     --
>     Matt Hellige / matt@... <mailto:matt@...>
>     http://matt.immute.net
>
>

[Alex Boisvert-3]

On 2/1/08, Germán Buela <gbuela@...> wrote:

Hi Alex,
Regarding the example you posted with a Unix scala script to wire
things together... I have 2 questions:
1) You say this way you can keep the wiring out of application code:
is it a desirable goal to keep it outside of the deployable package
(WAR)? I'm used to having a Spring XML file as part of the project and
I like to simply deliver the WAR for deployment, and everything should
work. How do you handle the script? Do you set it up the first time
only, documenting it as a requirement, and then just deliver a WAR?

You can do both:  your script embedded inside the .war, or load the script from an arbitrary location. (More on this in my next message to David Bernard)

2) Noting that the script is OS specific, how would you handle it in
an environment where developers work on a given OS (ie Windows) but
the servers are a different one (ie Solaris)? I suppose developers
would have an alternative version of the script, but if there are
changes it can get tricky...

The script I provided was an example of bootstrap under Unix/Linux.  It's a convenience instead of using "scala myscript.scala".  If you want something that's portable across platform, you just need to separate the bootstrap (shell script) from the scala script and distribute something like,

foo.sh (Linux/MacOS/Solaris)
foo.cmd  (Windows 2000+)
foo.bat (Windows 95/98)
foo.scala (The portable scala code)

alex

[Alex Boisvert-3]

Hi David,

In a Servlet environment, you'd write an implementation of javax.servlet.ServletRequestListener (Servlet 2.4+) or a javax.servlet.Filter (Servlet 2.3) in which you would instantiate the interpreter and call the script like,

import scala.tools.nsc._

val interpreter = new Interpreter( new Settings(null) )
interpreter.compileString( fileToString("myscript.scala") )
interpreter.interpret("Boot.setup")

at which point your script code can call various methods on your Listener/Filter to bind request patterns to scala code, register shutdown hooks, etc.    This is very similar to what Spring offers, except the application context is built and wired using Scala code instead of an XML domain-specific language.

alex

On 2/2/08, David Bernard <david.bernard.31@...> wrote:

How do you use the script approach in a context (like a webapp) where the script isn't the main ?
How do you use scala as embedded script engine?

/davidB

Alex Boisvert wrote:
> Hi Matt,
>
> I agree with you Scala by itself (as it is today) it's not an ideal
> solution, but from my experience it beats using Spring/Guice.  The main
> advantages I see are,
>
> 1) No "impedance mismatch" between Java and Scala idioms; you can
> integrate code that follows different dependency-injection approaches
>     (constructor-injection, setter-injection, service lookup, ..., cake
> pattern, mix of Java and Scala)
> 2) Stronger typing (no XML or annotations)
> 3) No additional framework to learn
> 4) You have the full power of Scala at your disposal so you have more
> options for the structuring of configuration itself
>
> I'm also hopeful that the situation will improve with additional
> language support such as virtual classes, first-class properties, ideas
> from Sean McDirmid's SuperGlue language, etc.
>
> alex
>
>
> On 2/1/08, *Matt Hellige* <matt@... <mailto:matt@...>> wrote:
>
>     I agree with other replies, but in a more guarded way. I think the
>     need for a DI framework is somewhat reduced in Scala, as compared to
>     Java. But I definitely don't believe that the need is completely
>     eliminated. There are many things that Spring does that are not easy
>     to achieve without a framework. So I do advise that you look into the
>     patterns that people mentioned, but I also expect that people will
>     continue to use Spring/Guice/etc. with Scala and that eventually we
>     will see a new approach to DI that is a more natural fit with Scala's
>     naming conventions and language features.
>
>     Matt
>
>     On Feb 1, 2008 11:28 AM, Alex Boisvert <boisvert@...
>     <mailto:boisvert@...>> wrote:
>      >
>      > On 2/1/08, Stepan Koltsov <stepan.koltsov@...
>     <mailto:stepan.koltsov@...>> wrote:
>      >
>      >
>      > > Is there any way to write code in Scala as in Java+Spring? I.
>     e. with
>      > > dependency injection of components.
>      > >
>      > > It is hard to write large applications without DI.
>      > >
>      > > Should DI be done in pure Scala some way, or there is any
>     framework,
>      > > or Spring itself should be used?
>      >
>      > Hi Stepan,
>      >
>      > I see two sides to this story,
>      > -How to structure code to make it more configurable? (parametric)
>      > -How to wire parts together and provide configuration
>      >
>      > Scala's type system and concise syntax help you on both aspects
>     compared to
>      > Java.  I've posted a small example yesterday [1].
>      >
>      > Similarly to Java and other OO programming languages without open
>     classes,
>      > you want to reduce as much as possible static linking inside your
>      > application.  This typically implies two practices.  First, using
>     object
>      > factories instead of calling constructors directly; and second,
>     minimizing
>      > the use of singleton objects.  These practices apply to any part
>     or behavior
>      > that you want to be able to reconfigure.  It's okay to rely on static
>      > linking for things that you don't expect (or want to) change.
>     The "Cake
>      > Pattern" paper [2] discusses some of these considerations.
>      >
>      > In practice, I've found that using Scala scripts (using the
>     interpreter) was
>      > a better solution than Spring to wire pieces together and inject
>      > configuration parameter inside my applications.   There are some
>     issues with
>      > using Spring since Scala conventions for class naming, method naming
>      > (JavaBeans-style setters/getters) and overall application
>     structuring tend
>      > to differ from Java.  Some simple things work but you'll run into
>     issues
>      > with most complex scenarios.   As far as I know, nobody has tried
>     to resolve
>      > these issues or is working on a Scala dependency-injection framework.
>      >
>      > Hope this helps,
>      > alex
>      >
>      > [1]
>      >
>     http://www.nabble.com/Cake-pattern-and-dependency-injection-td15199303.html#a15208024
>      >  [2] http://lamp.epfl.ch/~odersky/papers/ScalableComponent.pdf
>
>
>
>     --
>     Matt Hellige / matt@... <mailto:matt@...>
>     http://matt.immute.net
>
>

[David Bernard-3]

Hi Alex,

Thanks for the info,
I like the script approach for assembly and property/xml for configuration (Spring mixe both)

I also ask about embedded interpreter to add an embedded interpreter and a macro handler for macro wrote in scala into jEdit ;).

I'll study the api of scala.tools.nsc.Interpreter.

Thx

/davidB

Alex Boisvert wrote:

> Hi David,
>
> In a Servlet environment, you'd write an implementation of
> javax.servlet.ServletRequestListener (Servlet 2.4+) or a
> javax.servlet.Filter (Servlet 2.3) in which you would instantiate the
> interpreter and call the script like,
>
> import scala.tools.nsc._
>
> val interpreter = new Interpreter( new Settings(null) )
> interpreter.compileString( fileToString("myscript.scala") )
> interpreter.interpret("Boot.setup")
>
> at which point your script code can call various methods on your
> Listener/Filter to bind request patterns to scala code, register
> shutdown hooks, etc.    This is very similar to what Spring offers,
> except the application context is built and wired using Scala code
> instead of an XML domain-specific language.
>
> alex
>
> On 2/2/08, *David Bernard* <david.bernard.31@...
> <mailto:david.bernard.31@...>> wrote:
>
>     How do you use the script approach in a context (like a webapp)
>     where the script isn't the main ?
>     How do you use scala as embedded script engine?
>
>     /davidB
>
>     Alex Boisvert wrote:
>      > Hi Matt,
>      >
>      > I agree with you Scala by itself (as it is today) it's not an ideal
>      > solution, but from my experience it beats using
>     Spring/Guice.  The main
>      > advantages I see are,
>      >
>      > 1) No "impedance mismatch" between Java and Scala idioms; you can
>      > integrate code that follows different dependency-injection approaches
>      >     (constructor-injection, setter-injection, service lookup,
>     ..., cake
>      > pattern, mix of Java and Scala)
>      > 2) Stronger typing (no XML or annotations)
>      > 3) No additional framework to learn
>      > 4) You have the full power of Scala at your disposal so you have more
>      > options for the structuring of configuration itself
>      >
>      > I'm also hopeful that the situation will improve with additional
>      > language support such as virtual classes, first-class properties,
>     ideas
>      > from Sean McDirmid's SuperGlue language, etc.
>      >
>      > alex
>      >
>      >
>      > On 2/1/08, *Matt Hellige* <matt@...
>     <mailto:matt@...> <mailto:matt@...
>     <mailto:matt@...>>> wrote:
>      >
>      >     I agree with other replies, but in a more guarded way. I
>     think the
>      >     need for a DI framework is somewhat reduced in Scala, as
>     compared to
>      >     Java. But I definitely don't believe that the need is completely
>      >     eliminated. There are many things that Spring does that are
>     not easy
>      >     to achieve without a framework. So I do advise that you look
>     into the
>      >     patterns that people mentioned, but I also expect that people
>     will
>      >     continue to use Spring/Guice/etc. with Scala and that
>     eventually we
>      >     will see a new approach to DI that is a more natural fit with
>     Scala's
>      >     naming conventions and language features.
>      >
>      >     Matt
>      >
>      >     On Feb 1, 2008 11:28 AM, Alex Boisvert <boisvert@...
>     <mailto:boisvert@...>
>      >     <mailto:boisvert@... <mailto:boisvert@...>>>
>     wrote:
>      >      >
>      >      > On 2/1/08, Stepan Koltsov <stepan.koltsov@...
>     <mailto:stepan.koltsov@...>
>      >     <mailto:stepan.koltsov@...
>     <mailto:stepan.koltsov@...>>> wrote:
>      >      >
>      >      >
>      >      > > Is there any way to write code in Scala as in
>     Java+Spring? I.
>      >     e. with
>      >      > > dependency injection of components.
>      >      > >
>      >      > > It is hard to write large applications without DI.
>      >      > >
>      >      > > Should DI be done in pure Scala some way, or there is any
>      >     framework,
>      >      > > or Spring itself should be used?
>      >      >
>      >      > Hi Stepan,
>      >      >
>      >      > I see two sides to this story,
>      >      > -How to structure code to make it more configurable?
>     (parametric)
>      >      > -How to wire parts together and provide configuration
>      >      >
>      >      > Scala's type system and concise syntax help you on both
>     aspects
>      >     compared to
>      >      > Java.  I've posted a small example yesterday [1].
>      >      >
>      >      > Similarly to Java and other OO programming languages
>     without open
>      >     classes,
>      >      > you want to reduce as much as possible static linking
>     inside your
>      >      > application.  This typically implies two
>     practices.  First, using
>      >     object
>      >      > factories instead of calling constructors directly; and
>     second,
>      >     minimizing
>      >      > the use of singleton objects.  These practices apply to
>     any part
>      >     or behavior
>      >      > that you want to be able to reconfigure.  It's okay to
>     rely on static
>      >      > linking for things that you don't expect (or want to) change.
>      >     The "Cake
>      >      > Pattern" paper [2] discusses some of these considerations.
>      >      >
>      >      > In practice, I've found that using Scala scripts (using the
>      >     interpreter) was
>      >      > a better solution than Spring to wire pieces together and
>     inject
>      >      > configuration parameter inside my applications.   There
>     are some
>      >     issues with
>      >      > using Spring since Scala conventions for class naming,
>     method naming
>      >      > (JavaBeans-style setters/getters) and overall application
>      >     structuring tend
>      >      > to differ from Java.  Some simple things work but you'll
>     run into
>      >     issues
>      >      > with most complex scenarios.   As far as I know, nobody
>     has tried
>      >     to resolve
>      >      > these issues or is working on a Scala dependency-injection
>     framework.
>      >      >
>      >      > Hope this helps,
>      >      > alex
>      >      >
>      >      > [1]
>      >      >
>      >    
>     http://www.nabble.com/Cake-pattern-and-dependency-injection-td15199303.html#a15208024
>      >      >  [2] http://lamp.epfl.ch/~odersky/papers/ScalableComponent.pdf
>      >
>      >
>      >
>      >     --
>      >     Matt Hellige / matt@... <mailto:matt@...>
>     <mailto:matt@... <mailto:matt@...>>
>      >     http://matt.immute.net
>      >
>      >
>
>

[Stepan Koltsov-2]

On 2/1/08, Jamie Webb <j@...> wrote:

> On 2008-02-01 19:18:53 Stepan Koltsov wrote:
> > Is there any way to write code in Scala as in Java+Spring? I. e. with
> > dependency injection of components.
> >
> > It is hard to write large applications without DI.
> >
> > Should DI be done in pure Scala some way, or there is any framework,
> > or Spring itself should be used?
>
> The code below (using the example from David's link) is a way to very
> closely model Spring-style autowiring using pure, immutable, type-safe
> Scala. I should say that I'm not necessarily recommending this style;
> there are a great many ways to skin this cat. For example the Cake
> pattern uses mixins to combine all the components into a single
> namespace.
>
> First define the services, exactly as usual:
>
>   trait OnOffDevice {
>       def on() : Unit
>       def off() : Unit
>   }
>
>   trait SensorDevice {
>       def isCoffeePresent : Boolean
>   }
>
>   class Heater extends OnOffDevice {
>       def on() {}
>       def off() {}
>   }
>
>   class PotSensor extends SensorDevice {
>       def isCoffeePresent = true
>   }
>
> Now the consumer. The dependencies are defined as a nested trait with
> an abstract instance. You could import it if you like, to avoid
> writing env.foo each time.
>
>   abstract class Warmer {
>       trait Env {
>           val potSensor : SensorDevice
>           val heater : OnOffDevice
>       }
>       protected val env : Env
>
>       def trigger() {
>           if(env.potSensor.isCoffeePresent) env.heater.on()
>           else env.heater.off()
>       }
>   }
>
> To build a configuration, we instantiate the objects:
>
>   val thePotSensor = new PotSensor
>   val theHeater = new Heater
>   val theWarmer = new Warmer { protected val env = new Config with Env }
>
> And name them, so that they will be wired together:
>
>   class Config {
>       lazy val potSensor = thePotSensor
>       lazy val heater = theHeater
>   }

This does not work well.

1. If Sensor component is used in two different places (in Warmer and
in Cooler), it will be instantiated twice.
2. Synax overhead: I have to declare each components two times: first
before Config class, and second inside Config.
3. Calling dependent component method seems to be much more expensive
then calling dependent component method in Spring's injection, because
of vitrual method call (possibly optimized), one more indirect pointer
access (env), and syncrhonization in lazy val.

Thank you for Idea, anyway.

> The trick is the 'new Config with Env', which allows us to take a
> single global Config class, and make it implement whatever Env each
> component requests. That's the bit you can't do in Java. Another
> possibility would be to use structural subtyping, which would save a
> few keystrokes for a slight performance hit.

[Stepan Koltsov-2]

David,

seems like it is not DI. You example:

===
trait Sensor {
}

class Heater {
  val sensor = SensorBuilder.buildSensor()
}

class RealSensor extends Sensor
class MockSensor extends Sensor
===

This code does not allow me to instantiate two Heater instances, one
for RealSensor, and another for MockSensor without modifying
SensorBuilder object.

On 2/1/08, David Pollak <dpp@...> wrote:

>
> object HttpBuilder {
>    var buildHttp: () => HttpThingIntf = new NormalHttpThing
>  }
>
>  // I want to change what is built by the HttpBuilder:
>
>
> HttpBuilder.buildHttp = () => new MockHttpThing
>
>  And to build a new HttpThing:
>
>
> val myHttpThing = HttpBuilder.buildHttp()
>  You can extend the paradigm with PartialFunctions:
>
>
> object HttpBuilder {
>    var buildHttp: PartialFunction[Unit, HttpThingIntf] = {
>      case _ => new NormalHttpThing
>    }
>  }
>  And you can modify the functionality with a conditional:
>
>
> HttpBuilder.buildHttp = {
>    case _ if someCondition => new Condition1HttpMock
>    case _ if someOtherCondition => new Condition2HttpMock
>  } orElse HttpBuilder.buildHttp

[Stepan Koltsov-2]

This is not dependency injection too. Example you shown does not work
with large number of components with complex dependencies between
them. You suggest to wire all dependecies explicitly in the single
place.

S.

On 2/1/08, Alex Boisvert <boisvert@...> wrote:

> On 2/1/08, Stepan Koltsov <stepan.koltsov@...> wrote:
>
> > Is there any way to write code in Scala as in Java+Spring? I. e. with
> > dependency injection of components.
> >
> > It is hard to write large applications without DI.
> >
> > Should DI be done in pure Scala some way, or there is any framework,
> > or Spring itself should be used?
>
> Hi Stepan,
>
> I see two sides to this story,
> -How to structure code to make it more configurable? (parametric)
> -How to wire parts together and provide configuration
>
> Scala's type system and concise syntax help you on both aspects compared to
> Java.  I've posted a small example yesterday [1].
>
> Similarly to Java and other OO programming languages without open classes,
> you want to reduce as much as possible static linking inside your
> application.  This typically implies two practices.  First, using object
> factories instead of calling constructors directly; and second, minimizing
> the use of singleton objects.  These practices apply to any part or behavior
> that you want to be able to reconfigure.  It's okay to rely on static
> linking for things that you don't expect (or want to) change.   The "Cake
> Pattern" paper [2] discusses some of these considerations.
>
> In practice, I've found that using Scala scripts (using the interpreter) was
> a better solution than Spring to wire pieces together and inject
> configuration parameter inside my applications.   There are some issues with
> using Spring since Scala conventions for class naming, method naming
> (JavaBeans-style setters/getters) and overall application structuring tend
> to differ from Java.  Some simple things work but you'll run into issues
> with most complex scenarios.   As far as I know, nobody has tried to resolve
> these issues or is working on a Scala dependency-injection framework.
>
> Hope this helps,
> alex
>
> [1]
> http://www.nabble.com/Cake-pattern-and-dependency-injection-td15199303.html#a15208024
>  [2]
> http://lamp.epfl.ch/~odersky/papers/ScalableComponent.pdf

[Jamie Webb-2]

On 2008-02-03 20:45:54 Stepan Koltsov wrote:
> This does not work well.
>
> 1. If Sensor component is used in two different places (in Warmer and
> in Cooler), it will be instantiated twice.

No, it won't. Read again.

> 2. Synax overhead: I have to declare each components two times: first
> before Config class, and second inside Config.

Well, if you want to reduce the keystrokes further, here's the version
I mentioned using structural subtyping:

  class Warmer(env : {
      val potSensor : SensorDevice
      val heater : OnOffDevice
  }) {
      def trigger() {
          if(env.potSensor.isCoffeePresent) env.heater.on()
          else env.heater.off()
      }
  }

  object Config {
      lazy val potSensor = new PotSensor
      lazy val heater = new Heater
      lazy val warmer = new Warmer(this)
  }

Quite pretty, really...

> 3. Calling dependent component method seems to be much more expensive
> then calling dependent component method in Spring's injection, because
> of vitrual method call (possibly optimized), one more indirect pointer
> access (env), and syncrhonization in lazy val.

'Much' is something of an overstatement here; we're still talking
the same sort of speed as a field lookup in most dynamic languages, and
you can make a local alias if you ever find it's a particular
bottleneck.

It's true that idiomatic Scala code is often not as efficient as the
equivalent Java. And the argument for why you shouldn't care if it
makes you more productive has been done to death a million times so I
won't repeat it.

/J