

ActiveSupport Considered Harmful - bjhess
http://hayesdavis.net/2010/07/26/activesupport-considered-harmful/

======
aaronbrethorst
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.

~~~
angelbob
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.

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

------
snprbob86
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.

------
richcollins
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
> Why not

Ugliness.

~~~
jerf
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.

------
DanielRibeiro
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.

------
blaix
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
It seems crazy to me that someone would build a gem that expects the user to
already have Rails installed. =:-o

~~~
blaix
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.

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

~~~
angelbob
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.

~~~
jamesbritt
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.

~~~
dhh
Active Support 3 offers piece meal inclusion. You can grab it all at once or
bit by bit as you please.

