To summarize the argument: ActiveSupport is awesome because it has all kinds of fantastic features that Ruby lacks out of the box. But don't use ActiveSupport in your gems because it's going to cause all kinds of crazy dependency issues in folks' applications, whether or not they use Rails!
It strikes me that what's really harmful here is the glacial pace of change in the Ruby Standard Library. Of course, we shouldn't see untried and untested functionality shoved into the standard library willy-nilly: pollution of the standard library with ill-thought-out code is probably even worse.
But, that said, Rails 1.0 came out almost five years ago. In the same time span, we've seen the release of Ruby 1.8.4-7 and 1.9.0 and 1.9.1. It was big news in 2007 when Rails' Object#tap method made it into 1.8.7 and 1.9.
We should be seeing more of this functionality pulled out of ActiveSupport and pushed into the Ruby Standard Library.
Part of the problem here is that in the ridiculously fast-moving Ruby and Rails world, you need <i>something</i> reasonably stable. The standard libraries could speed up, but would then need to worry more about bad ideas making it in with no way to take them out.
Backwards compatibility isn't optional here. Ruby could very, very quickly become a giant ball of hair if we're not careful what we put in, because nothing can come back out. Rails plays fast and loose with this, but having the language itself do so is really, really bad.
In summary, you mark a method as "implicit" which constructors a decorator object with your extension methods. Implicits must be explicitly brought into scope and any ambiguities are a compile time error. This model is much more robust than Ruby's, but owes a lot of it's error-prevention to clever use of static typing.
This is the whole issue with open classes and many libraries (transitive dependencies make this issue exponentially more likely, on the number of libraries).
I have commented on this issue a while back (http://bit.ly/cNez8i), and some people were kind enough to fork ruby (http://gist.github.com/358467) and enable scoped Open Classes, like Scala, Groovy and C# have. This is great for dsls (many dsls that change base classes can happily live in the same project without conflicting with each other) and libraries (I can do whatever I want in my library, extending Object, Enumerable and Kernel, left and right, and the users will not be affected).
However, this very openness made the "moving to a newer and better version of ruby" movement harder. Just hope 2.0 will set things right.
Disclaimer: open classes are great. I think they should be allowed, only highly discouraged for libraries and frameworks, who should stick with scoped open classes for most of the time.
Title is a bit sensationalist, but he makes a great point. It's ok to be a little less DRY and implement your own helper methods in the namespace of your gem rather than include the whole low-level object invasion of active_support.
Well, it expects the user to have the activesupport gem installed. Rails depends on it, not the other way around. But yeah, usually if you've installed one you've installed the whole rails bundle.
It's fairly rare, honestly. You see it occasionally, but it's often a pain when you do.
Interestingly, Facets (a non-Rails support library similar in scope to AR) has exactly the same problem. So mostly this is an argument against similar broad support libraries outside any specific scope.
That is, Facets would be pointless by this argument because it has no Rails-like environment to live in.
I agree that it's reasonably rare (though anecdotally I do feel like I'm running into it more often).
It's correct that I'm essentially arguing against requiring "invasive" support libraries that change the nature of ruby (admittedly, that's subjective) in gems. Gem authors should consider their dependencies on the basis of necessity, not convenience. Keep the scope low and compatibility high.
The nice thing about facets is that you can include just the items you're interested in. You don't need to pull in every method defined in the library.
It strikes me that what's really harmful here is the glacial pace of change in the Ruby Standard Library. Of course, we shouldn't see untried and untested functionality shoved into the standard library willy-nilly: pollution of the standard library with ill-thought-out code is probably even worse.
But, that said, Rails 1.0 came out almost five years ago. In the same time span, we've seen the release of Ruby 1.8.4-7 and 1.9.0 and 1.9.1. It was big news in 2007 when Rails' Object#tap method made it into 1.8.7 and 1.9.
We should be seeing more of this functionality pulled out of ActiveSupport and pushed into the Ruby Standard Library.