4 ms·

ActiveSupport Considered Harmful

41 points by bjhess 16y ago

snprbob86 16y 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 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.
blaix 16y 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 16y ago
  It seems crazy to me that someone would build a gem that expects the user to already have Rails installed. =:-o
  - blaix 16y 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.
aaronbrethorst 16y 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 16y ago
  It would be even better to see support for scoped namespaces in Ruby...
- angelbob 16y 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.
  - aaronbrethorst 16y ago
    I agree completely with you. I want to see a middle ground between glacial and fast-and-loose.
  - regularfry 16y ago
    Speed of progress wouldn't be a problem if people stuck to a sane and consistent version numbering system.
henning 16y ago
What is the scope of this issue? Most well-written Ruby code on github I see doesn't use ActiveSupport.
- angelbob 16y 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 16y 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 16y 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.
    - dhh 16y ago
      Active Support 3 offers piece meal inclusion. You can grab it all at once or bit by bit as you please.
richcollins 16y 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 16y ago
  > Why not Ugliness.
  - jerf 16y 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.
DanielRibeiro 16y 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 http://bit.ly/cNez8i), and some people were kind enough to fork ruby (http://gist.github.com/358467 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.

41 points by bjhess 16y 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 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.

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

aaronbrethorst 16y 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 16y ago
It would be even better to see support for scoped namespaces in Ruby...
angelbob 16y 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.
- aaronbrethorst 16y ago
  I agree completely with you. I want to see a middle ground between glacial and fast-and-loose.
- regularfry 16y ago
  Speed of progress wouldn't be a problem if people stuck to a sane and consistent version numbering system.

henning 16y ago

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

angelbob 16y 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 16y 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 16y 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.
  - dhh 16y ago
    Active Support 3 offers piece meal inclusion. You can grab it all at once or bit by bit as you please.

richcollins 16y 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 16y ago
> Why not Ugliness.
- jerf 16y 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.

DanielRibeiro 16y 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 http://bit.ly/cNez8i), and some people were kind enough to fork ruby (http://gist.github.com/358467 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.