Sunday, December 14, 2008

IoC in ruby, python and lack of autowiring

In my last post I waxed joyously about my love of IoC containers which are third party libs that track all my dependencies.

Now I've been trying to play around with Python and a bit of Ruby lately, and while I just adore the lack of getting decoupling for free (duck-typing gives you this), I enjoy the lack of compiling and I enjoy getting to have a fresh look as a programmer at languages I used to use as an admin for simple scripts.

However, the love fest and productivity ends when I realize I've lost my beloved auto-wiring of dependency management I get with things like Castle Windsor.

Most of the ruby and python IoC containers I found were no longer in active development and were started back when IoC was taking off in Java back in 2004 or so, namely Needle, Copland and py-container.

So I've looked at Spring Python which is active, looks nice and all, but I have to explicitly map components myself. You do get Aspects, service location, and some framework helpers like security, and transaction managment, but without auto-wiring ..... I have to be honest may not be worth it to me at all in a dynamic language.

So this leaves me in a bind. I've been convinced that dynamic languages are the future, staticly compiled languages keep moving that way, but now that i've learned all these awful tricks to make static languages more flexible, and in the meantime found the joy of IoC autowiring....seems like I'm stuck being most productive still in statically compiled languages.

The only alternative I forsee right now if I keep developing in Ruby or Python is build alot of factory classes to tie together large junks of dependency injected code.

Hopefully, I can find an autowiring IoC container for one of my dynamic languages of choice but I dont see how easy it'll be.

No comments: