I actually agree with you that the conversations was lacking some context. I wrote a blog some months back about design using traits<http://suereth.blogspot.com/2009/02/how-should-traits-in-scala-be-used.html>, however I thought I'd include some new thoughts/insights here.
There is a method of performing Dependency injection that is slightly more verbose than guice, but can be done at compile time, without any libraries. It's merely a design pattern, known as the "cake" pattern. It's actually how the Scala compiler itself is designed. For a better article on this technique (not in the show notes) see: http://jonasboner.com/2008/10/06/real-world-scala-dependency-injection-di.html I'm not an amazing fan of this pattern (although I've used it on a project). There's a little too much heavy-lifting (basically writing spring's "BeanContext" in a serious of layers) for my tastes. It does have the benefit of *not* being a library, (unless you consider scala a library), but that doesn't hold too much weight for me (I mostly do JEE these days... so I can deal with a lot of .jar files). One thing I will say is that this Cake pattern is more flexible than classic dependency injection, as long as you're willing to write the code. Perhaps IDE support could automate the generation of "Repository" traits. In the meantime I recommend reading Scalable Component Abstractions<http://lamp.epfl.ch/%7Eodersky/papers/ScalableComponent.pdf>for no purpose other than to better your existing design skills. More importantly, I'm not an amazing fan of this design approach for "dynamic" modularity. OSGi provides the ability to inject modules into a running system at runtime. I was talking with a colleague the other day who actually uses the following system: * All aspects of the software are designed as sub-components and OSGi-modularized * A DSL (pick any language) is written to configure the appliaction. (Note Spring 3.0 is supporting this style of configuration, as mentioned in the Rod Johnson interview podcast) * A "configuration" module wires the application together. There is a separate "configuration" module per customer. You can determine the needed modules for the application by this modules dependencies. * When doing live upgrades, the new subcomponents are deployed to the live up and a new "configuration" module is included. If the configuration module knows how to piece-meal come down and bring up subcompoenents, you can perform live updates. >From my colleagues perspect, this architecture was very helpful. I have not been able to put it into practice, but I keep it in my "bag o' tricks" for the next application that might require the flexibility. I thought others may be interested and/or used this technique. Anyway, in conclusion: I think the cake pattern is useful and has helped make me a better programmer but I don't use it on a macro level in practice. I believe there are other features required (virtual classes perhaps) that would make modularization better on the whole. It is my opinion that to help write more modular code, you need to be able to treat a Large system as a small system i.e. I need to start seeing ways of doing "module/package inheritance" and "module/package visibilities" etc. Scala provides a lot of these out of the box (private qualifiers, traits + nested class ecosystems), but I do not think it's there yet. However, seeing the new features in Scala 2.8.0, I don't think you'll have to wait long for new solutions to arise. I think these solutions may require new language features to become "easy" enough to be widely used. I beleive once Scala starts utilizing jigsaw/OSGi related features directly, it will become an ideal language for writing modular software. - Josh On Wed, May 20, 2009 at 6:31 AM, Reinier Zwitserloot <[email protected]>wrote: > > Was it just me, or did it feel like that particular aspect of 'scala > is so cool' totally blew up? > > creating objects with the 'with' statement just isn't a good way to > modularize. It would be if: > > you create 1 scala file that's an app, which creates an object via > 'with' expansion with just the 'modules' you need, and feed this to > scalac. If scalac then somehow built a dependency tree and compiled > exactly every file that's needed to make this work, but no other ones > (which can involve also picking up .java, groovy, jruby, and jython > sources!), *AND* this then triggered a cascade that used these sources > itself as the keys to figuring out which static files and other > dependencies are required, and then outputted this all to a neat > little bundle, *THEN* this would be a great modularization tool. And, > on top of that, to fulfill the stated requirement that clients that > didn't pay for module X don't even get module X, you should be able to > state which files should definitely NOT be included, and scalac should > then generate errors if it cannot complete the compile job without > compiling those files, which indicates that there are dependencies > between modules that you never intended and are hence bugs. That'd be > a fine utility, but scala doesn't do any of this. > > > The only way in which this helps, is if your build tool already has > the facilities to compile exactly which code you want (and not compile > the code you DONT want), and the 'with' tactic is used only to create > a few custom bootstrapping classes. However, if everything's already > compiled properly because of a build tool, and all you really need to > do is create a bootstrap class that knows exactly which code entry > points to fire up, then there are much better tools out there in java > land (which you can of course use in scala as well!)! > > - guice should help you with this. Incidentally, guice 2.0 has been > released this week. http://code.google.com/p/google-guice/ > > - The SPI system can help here. The custom compile job (e.g. ant > script) generates the right SPI pointer files, and your one main class > (instead of the many little ones approach that scala has) will use SPI > discovery. This is sort of a roll-your-own lightweight guice deal, but > it has the upside of not requiring an external library*. More info on > SPI can be found here: > > http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html#Service%20Provider > > *) Is anyone else bothered by the fact that 'requires external > library' is such an annoyance? That's a rather serious detriment to > code reuse and the whole schtick where java would rather defer to a > library that which other languages do in the language space (something > Joe Darcy, project coin lead, mentions every other email to the coin- > dev list, for example). I wish java shipped out of the box with a > lightweight ivy, or better yet, that javac itself compiled to BigJars > instead of class files and had a feature for stating dependencies in > source files (per module?) which javac would automatically chase down > for you. Eh. I'll keep dreaming. > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
