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