Merb slices, again
Michael Klishin keeps a great blog for updates to Merb, and I follow his posts regularly. I was a bit bemused to read his latest post about merb-slices, however:
The difference with Rails Engines is that merb-slices use Merb core API for plugins, and nothing else. It does not do crazy black magic, it does not use guesses and Ruby introspection to hook into framework boot process at “god knows when” point in time. It utilizes idea of merb-core to just be simple to extend. Where Rails engines add layers of magic by hooking into complicated Rails boot process with magical alias method chain, it also did not rely just on API in version 1.x. When Rails 2.0 came out with plugins API being refactored, Engines collapse on upgrade of your app.
Certainly in the past, the interaction between the engines plugin and Rails updates has been… well, interesting. That’s because at the time, the Rails core developers took a stance that they didn’t want to support ‘slice’ style development. The plugin mechanism in Rails 1.0 was simple and unsophisticated, so we had to do ‘crazy black magic’, as you call it, to get engines to work.
However, times have changed. Please take a look at how the plugin mechanism works in Rails 2.0. It’s designed to be cleanly extensible, so you don’t need to resort to ‘black magic’, and hopefully it succeeds at that. And a lot of those improvements have been a result (directly or indirectly) of the things I felt plugins should be able to do - the things that the engines plugin originally patched in. If you need some evidence of this, the current plugin mechanism was implemented by, well, me.
Probably future versions of Engines, like 2.5 or 3.0 will be much much cleaner and won’t use hacks, I do not know. I just think that Slices and Engines example shows how simple and modular code applied to simple task (extand darn load paths and register some routes; it is that simple) is beautiful, does not break and easy to comprehend compared to monuments of personal cleverness. It also shows how easy it is to hook into Merb boot process using one simple convention.
There are a couple of things going on here. Firstly, I think it’s great that merb can support changes in it’s behaviour very easily. As I said a few days back, to have that kind of extensibility supported cleanly by the framework makes life a lot easier. So Michael’s point here could just be that merb is cleaner internally that Rails is. Fine.
But - “Probably future versions of Engines, like 2.5 or 3.0 will be much much cleaner and won’t use hacks” - huh? Please point out the hacks you’re refering to. Have you actually looked at the engines plugin source code recently? This post reads to me as classic FUD about engines, feeding misconception back into public opinion because you don’t want ‘merb-slices’ to be attacked in the same way that Rails engines were a couple of years back.
It’s fine if you think that merb is ‘better’ than Rails, but if you’re going to decry code as hacky, at least be constructive about it.