Inversion of Control (IoC)

Okay, so I realize that a lot of folks are gonna expect me to trash some venerable object-oriented programming (OOP) design pattern. I suspect I'm fairly growing a reputation for it if I haven't already. But actually this blog is going to be a little different.

I've been working on the Galleon project recently and originally I wasn't going to install ColdSpring, but I discovered that it's actually a requirement for the latest release of Model-Glue. In the process of doing the research, in spite of the fact that I haven't been converting any of Ray's code to use any IoC frameworks, I've seen some things that I hadn't seen before. And I can understand why some folks would value having an IoC framework in spite of the fact that I'm still not entirely sold on them personally.

I may even be convinced to create an IoC component in the onTap framework core release as a facade that would be capable of providing access to any given 3rd-party IoC framework (ColdSpring, Lightwire, etc.). From the outside it would look similar to the ColdBox IoC plugin -- meaning that's how your code would interact with it, although the internal code would be designed with an eye toward supporting more than just ColdSpring or Lightwire and may even provide some of its own functionality on top.

Mostly I just wonder how much of a selling point this would be? Would it really turn people on to the idea of trying the onTap framework if I added an IoC facade?