Cake pattern and Spring style XML IOC

Dependency injection done with traits and self type annotation is indeed, as you say "hard wired".

The way I see it, dynamic re wiring as a feature is very much overated.

How often are systems "rewired" without the rewiring being part of a release
cycle (code change, tests, build, automated tests, deploy) ?

The only thing gained with the dynamic rewiring is that you save yourself a restart of the VM.
In both cases you are changing code (if you consider XML as code..)

With a wiring mechanism built into the language, you get the Scala compiler to do the validation,
not a plethora of XML tools that bring half a dozen of Jars in you system and complexifies your build,
bootstraping, etc.

The recompile+restart that comes with static rewiring is a small sacrifice to make
in exchage for the compile time validation and the reduced complexity in my opinion.

Cheers


On Thu, Aug 5, 2010 at 10:46 PM, Andrew Milkowski <andrewmilkowski [at] gmail [dot] com> wrote:

While reviewing cake pattern I noticed use of what is known as "self type annotations" to accomplish IOC but these annotations are hard-wired into a trait ie

Trait SomeTrait {
self: SomeTraitComponentA
self: SomeTraitComponentB
...
...
}

Then if a concrete class wants to behave like components in SomeTrait it needs to extended it with all its member components

And so it makes sense, but what I fail to see (unlike Spring) is that IOC can be accomplished by having a specifically crafted xml file which can auto-wire component construction at the run time, in cake such components are pre-wired in self annotating trait,

Hence the question, is there a way in scala (call it scala spring) to emulate this style of IOC, (via xml) or is this discouraged and preference is towards construction of traits with specific behaviour or differently put it: discourage "meta programming"

Thanks much!
Sent from my Verizon Wireless BlackBerry

Hi Andrew,

the XML configuration of spring is replaced by Scala code that does the
wiring. In other words there is no difference regarding being "dynamic".
The great advantage is that the Scala code is type safe whereas XML
configuration files may contain invalid class names.

--Stefan

Am 06.08.2010 04:46, schrieb Andrew Milkowski:
> While reviewing cake pattern I noticed use of what is known as "self type annotations" to accomplish IOC but these annotations are hard-wired into a trait ie
>
> Trait SomeTrait {
> self: SomeTraitComponentA
> self: SomeTraitComponentB
> ...
> ...
> }
>
> Then if a concrete class wants to behave like components in SomeTrait it needs to extended it with all its member components
>
> And so it makes sense, but what I fail to see (unlike Spring) is that IOC can be accomplished by having a specifically crafted xml file which can auto-wire component construction at the run time, in cake such components are pre-wired in self annotating trait,
>
> Hence the question, is there a way in scala (call it scala spring) to emulate this style of IOC, (via xml) or is this discouraged and preference is towards construction of traits with specific behaviour or differently put it: discourage "meta programming"
>
> Thanks much!
> Sent from my Verizon Wireless BlackBerry
>
>

Can't come up with a solid counter argument , if scala adaptation enters next phase (I am sure it will) all it has to be done is to introduce scala teaching together (with let say c++ for native embedded applications:) possibly some of these frameworks will start disappearing:) thanks much

Sent from my Verizon Wireless BlackBerry

From: Maxime Lévesque <maxime [dot] levesque [at] gmail [dot] com> Date: Fri, 6 Aug 2010 00:37:34 -0400To: <andrewmilkowski [at] gmail [dot] com>Cc: scala-user<scala-user [at] listes [dot] epfl [dot] ch>Subject: Re: [scala-user] Cake pattern and Spring style XML IOC

Dependency injection done with traits and self type annotation is indeed, as you say "hard wired".

The way I see it, dynamic re wiring as a feature is very much overated.

How often are systems "rewired" without the rewiring being part of a release
cycle (code change, tests, build, automated tests, deploy) ?

The only thing gained with the dynamic rewiring is that you save yourself a restart of the VM.
In both cases you are changing code (if you consider XML as code..)

With a wiring mechanism built into the language, you get the Scala compiler to do the validation,
not a plethora of XML tools that bring half a dozen of Jars in you system and complexifies your build,
bootstraping, etc.

The recompile+restart that comes with static rewiring is a small sacrifice to make
in exchage for the compile time validation and the reduced complexity in my opinion.

Cheers


On Thu, Aug 5, 2010 at 10:46 PM, Andrew Milkowski <andrewmilkowski [at] gmail [dot] com> wrote:

While reviewing cake pattern I noticed use of what is known as "self type annotations" to accomplish IOC but these annotations are hard-wired into a trait ie

Trait SomeTrait {
self: SomeTraitComponentA
self: SomeTraitComponentB
...
...
}

Then if a concrete class wants to behave like components in SomeTrait it needs to extended it with all its member components

And so it makes sense, but what I fail to see (unlike Spring) is that IOC can be accomplished by having a specifically crafted xml file which can auto-wire component construction at the run time, in cake such components are pre-wired in self annotating trait,

Hence the question, is there a way in scala (call it scala spring) to emulate this style of IOC, (via xml) or is this discouraged and preference is towards construction of traits with specific behaviour or differently put it: discourage "meta programming"

Thanks much!
Sent from my Verizon Wireless BlackBerry

Actually I see an emergence of "D language" with its use of mixins (and no multiple inheritance) I wonder if this was "borrowed" from scala:) speaking of adaptation it is important question, from my end I tried to find "an achilles" point the only one I can see is that I did not study lambda calculus in the undergrad hard enough:)

Sent from my Verizon Wireless BlackBerry

From: "Andrew Milkowski" <andrewmilkowski [at] gmail [dot] com> Date: Fri, 6 Aug 2010 11:34:47 +0000To: Maxime Lévesque<maxime [dot] levesque [at] gmail [dot] com>ReplyTo: andrewmilkowski [at] gmail [dot] com Cc: scala-user<scala-user [at] listes [dot] epfl [dot] ch>Subject: Re: [scala-user] Cake pattern and Spring style XML IOC
Can't come up with a solid counter argument , if scala adaptation enters next phase (I am sure it will) all it has to be done is to introduce scala teaching together (with let say c++ for native embedded applications:) possibly some of these frameworks will start disappearing:) thanks much

Sent from my Verizon Wireless BlackBerry

From: Maxime Lévesque <maxime [dot] levesque [at] gmail [dot] com> Date: Fri, 6 Aug 2010 00:37:34 -0400To: <andrewmilkowski [at] gmail [dot] com>Cc: scala-user<scala-user [at] listes [dot] epfl [dot] ch>Subject: Re: [scala-user] Cake pattern and Spring style XML IOC

Dependency injection done with traits and self type annotation is indeed, as you say "hard wired".

The way I see it, dynamic re wiring as a feature is very much overated.

How often are systems "rewired" without the rewiring being part of a release
cycle (code change, tests, build, automated tests, deploy) ?

The only thing gained with the dynamic rewiring is that you save yourself a restart of the VM.
In both cases you are changing code (if you consider XML as code..)

With a wiring mechanism built into the language, you get the Scala compiler to do the validation,
not a plethora of XML tools that bring half a dozen of Jars in you system and complexifies your build,
bootstraping, etc.

The recompile+restart that comes with static rewiring is a small sacrifice to make
in exchage for the compile time validation and the reduced complexity in my opinion.

Cheers


On Thu, Aug 5, 2010 at 10:46 PM, Andrew Milkowski <andrewmilkowski [at] gmail [dot] com> wrote:

While reviewing cake pattern I noticed use of what is known as "self type annotations" to accomplish IOC but these annotations are hard-wired into a trait ie

Trait SomeTrait {
self: SomeTraitComponentA
self: SomeTraitComponentB
...
...
}

Then if a concrete class wants to behave like components in SomeTrait it needs to extended it with all its member components

And so it makes sense, but what I fail to see (unlike Spring) is that IOC can be accomplished by having a specifically crafted xml file which can auto-wire component construction at the run time, in cake such components are pre-wired in self annotating trait,

Hence the question, is there a way in scala (call it scala spring) to emulate this style of IOC, (via xml) or is this discouraged and preference is towards construction of traits with specific behaviour or differently put it: discourage "meta programming"

Thanks much!
Sent from my Verizon Wireless BlackBerry

Another way to do this is to skip the cake pattern but use Spring
JavaConfig instead of XML to do the dependency injection.

Spring JavaConfig is an add on project for Spring 2.5 that is now built
into Spring 3.

In our case, we write the "JavaConfig" in Scala. So you can still
dynamically inject what you need and get the javac or scalac to check
that all the correct types are being injected into the correct places.

The nice thing about this is that you can get configuration parameters
from the properties file and convert things into Scala types:

@AnnotationDrivenTx { val transactionManager = "db_txn_manager" }
@Configuration { val defaultLazy = Lazy.TRUE }
@PropertiesValueSource { val locations = Array("classpath:foo.properties") }
abstract class ApplicationConfig
{
@ExternalValue("facility_static.use")
def use_facility_static_str : String

@Bean
def use_facility_static : Boolean =
{
val s = use_facility_static_str.toLowerCase
(s == "true") || (s == "yes") || (s == "1")
}

@ExternalValue("db.schema_name")
def db_schema_name : String

// ### Until http://lampsvn.epfl.ch/trac/scala/changeset/17396 makes
// ### it into an offical Scala release, this bean cannot hold a
// ### scala.None. So for now, do not make it a bean. Also see
// ### http://lampsvn.epfl.ch/trac/scala/ticket/2098 .
// @Bean
def db_schema_name_opt : Option[String] =
{
if (db_schema_name.length == 0) {
None
}
else {
Some(db_schema_name)
}
}
}

Regards,
Blair

On 08/05/2010 11:50 PM, Stefan Wachter wrote:
> Hi Andrew,
>
> the XML configuration of spring is replaced by Scala code that does the
> wiring. In other words there is no difference regarding being "dynamic".
> The great advantage is that the Scala code is type safe whereas XML
> configuration files may contain invalid class names.
>
> --Stefan
>
>
> Am 06.08.2010 04:46, schrieb Andrew Milkowski:
>> While reviewing cake pattern I noticed use of what is known as "self type annotations" to accomplish IOC but these annotations are hard-wired into a trait ie
>>
>> Trait SomeTrait {
>> self: SomeTraitComponentA
>> self: SomeTraitComponentB
>> ...
>> ...
>> }
>>
>> Then if a concrete class wants to behave like components in SomeTrait it needs to extended it with all its member components
>>
>> And so it makes sense, but what I fail to see (unlike Spring) is that IOC can be accomplished by having a specifically crafted xml file which can auto-wire component construction at the run time, in cake such components are pre-wired in self annotating trait,
>>
>> Hence the question, is there a way in scala (call it scala spring) to emulate this style of IOC, (via xml) or is this discouraged and preference is towards construction of traits with specific behaviour or differently put it: discourage "meta programming"
>>
>> Thanks much!
>> Sent from my Verizon Wireless BlackBerry
>>
>>
>

Excellent thanks! (nice way also to send configuration params) overall this adds to design flexibility I still need to look deeper at the configgy to see how configuration can be "reloaded" live...
Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: Blair Zajac
Date: Fri, 06 Aug 2010 09:35:02
To: Stefan Wachter
Cc:
Subject: Re: [scala-user] Cake pattern and Spring style XML IOC

Another way to do this is to skip the cake pattern but use Spring
JavaConfig instead of XML to do the dependency injection.

Spring JavaConfig is an add on project for Spring 2.5 that is now built
into Spring 3.

In our case, we write the "JavaConfig" in Scala. So you can still
dynamically inject what you need and get the javac or scalac to check
that all the correct types are being injected into the correct places.

The nice thing about this is that you can get configuration parameters
from the properties file and convert things into Scala types:

@AnnotationDrivenTx { val transactionManager = "db_txn_manager" }
@Configuration { val defaultLazy = Lazy.TRUE }
@PropertiesValueSource { val locations = Array("classpath:foo.properties") }
abstract class ApplicationConfig
{
@ExternalValue("facility_static.use")
def use_facility_static_str : String

@Bean
def use_facility_static : Boolean =
{
val s = use_facility_static_str.toLowerCase
(s == "true") || (s == "yes") || (s == "1")
}

@ExternalValue("db.schema_name")
def db_schema_name : String

// ### Until http://lampsvn.epfl.ch/trac/scala/changeset/17396 makes
// ### it into an offical Scala release, this bean cannot hold a
// ### scala.None. So for now, do not make it a bean. Also see
// ### http://lampsvn.epfl.ch/trac/scala/ticket/2098 .
// @Bean
def db_schema_name_opt : Option[String] =
{
if (db_schema_name.length == 0) {
None
}
else {
Some(db_schema_name)
}
}
}

Regards,
Blair

On 08/05/2010 11:50 PM, Stefan Wachter wrote:
> Hi Andrew,
>
> the XML configuration of spring is replaced by Scala code that does the
> wiring. In other words there is no difference regarding being "dynamic".
> The great advantage is that the Scala code is type safe whereas XML
> configuration files may contain invalid class names.
>
> --Stefan
>
>
> Am 06.08.2010 04:46, schrieb Andrew Milkowski:
>> While reviewing cake pattern I noticed use of what is known as "self type annotations" to accomplish IOC but these annotations are hard-wired into a trait ie
>>
>> Trait SomeTrait {
>> self: SomeTraitComponentA
>> self: SomeTraitComponentB
>> ...
>> ...
>> }
>>
>> Then if a concrete class wants to behave like components in SomeTrait it needs to extended it with all its member components
>>
>> And so it makes sense, but what I fail to see (unlike Spring) is that IOC can be accomplished by having a specifically crafted xml file which can auto-wire component construction at the run time, in cake such components are pre-wired in self annotating trait,
>>
>> Hence the question, is there a way in scala (call it scala spring) to emulate this style of IOC, (via xml) or is this discouraged and preference is towards construction of traits with specific behaviour or differently put it: discourage "meta programming"
>>
>> Thanks much!
>> Sent from my Verizon Wireless BlackBerry
>>
>>
>