ActiveSupport Considered Harmful

http://hayesdavis.net/2010/07/26/activesupport-considered-harmful/

by bjhess • 16 years ago

41 18 16 years ago

blaix2• 16 years ago

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.

sabat• 16 years ago

It seems crazy to me that someone would build a gem that expects the user to already have Rails installed. =:-o

blaix2• 16 years ago

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.

aaronbrethorst2• 16 years ago

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.

CodeMage• 16 years ago

It would be even better to see support for scoped namespaces in Ruby...

angelbob2• 16 years ago

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.

aaronbrethorst2• 16 years ago

I agree completely with you. I want to see a middle ground between glacial and fast-and-loose.

regularfry• 16 years ago

Speed of progress wouldn't be a problem if people stuck to a sane and consistent version numbering system.

henning• 16 years ago

What is the scope of this issue? Most well-written Ruby code on github I see doesn't use ActiveSupport.

angelbob2• 16 years ago

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.

hayesdavis• 16 years ago

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.

jamesbritt• 16 years ago

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.

richcollins• 16 years ago

Why not just ask the object for a proxy and then send it messages? Then you only add one method to the base object in question.

  [1, 2, 3].as.sum

jules• 16 years ago

> Why not

Ugliness.

jerf• 16 years ago

Given a choice between "pretty and wrong" and "ugly and correct", I'll take "ugly and correct". The beauty that hides evil is not the true beauty.

snprbob86• 16 years ago

I'm new to Scala, but I love their alternative with the colorful name "Pimp My Library": http://scala.sygneca.com/patterns/pimp-my-library

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.

DanielRibeiro• 16 years ago

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.

ActiveSupport Considered Harmful

Related Stories