squeel

This is a nice article about the subtleties of instance_eval in Ruby. It's an interesting feature that powers some very clever DSLs [1][2][3]. At the same time it's a feature that is confusing and should be avoided as much as possible. One reason is that it is impossible to predict by looking at the calling code in which context a block is executed if instance_eval is used. Another reason is that a block that is executed with instance_eval cannot reference instance variables of the calling object. No problem for trivial code, but a huge headache for slightly more complex code or for views in Rails apps (which use instance variables to pass objects from controllers to views). And unlike the inability to call local helper methods (as explained at the end in the article) this cannot be worked around by throwing more magic into the mix. I be

Comments aren't available on the article, so a couple of quick clarifications here: Nitpicky, but ActiveRecord::Relation is not ARel. ARel is the relational algebra library that underpins ActiveRecord (>=3.0). See http://erniemiller.org/2010/05/11/activerecord-relation-vs-a... for more info. The specific example he used to demonstrate worked transparently because of the has_many :through relationship for users on Article, which requires the collaborations table to filter the users, so joins it. Otherwise, you would need to do the join yourself before merging the scope, and things get messy pretty quickly, especially if you end up with table aliases (which the merged relation knows nothing about -- it will still query against the collaborations table). I added "sifters" to Squeel (http://github.com/ernie/squeel) in order to address the nee