This code is extracted/adapted from Mat Brown's Sunspot gem. One of Sunspot's nicest features is an expressive DSL for defining search indexes and performing queries. It works by `instance_eval`-ing a block you pass into it in the context of its own search builder object. In this code, the `pig thing1` statement is roughly equivalent to `zoo = Zoo.new; zoo.pig(thing1)`. Sunspot's DSL has to resort to trickery: the `instance_eval_with_context` method uses `eval` to get the block to give up the object it considers to be `self`, then sets up an elaborate system of delegates and `method_missing` calls so any methods not handled by the DSL are forwarded to the surrounding object. But as a result, this syntax is minimal and beautiful, _and_ it works the way you expect whether or not you prefer blocks to yield an object. Without this trick the block would be restricted to _either_ the original, "calling" context (as a closure) or the DSL's "receiving" context (using `instance_eval`), but not both. #### Using `instance_eval` for cleaner syntax ```ruby Carburetor.search do # This will raise NoMethodError; this block is executing in the context of # a Carburetor search builder and has no access to data from the controller. keywords params[:query] end ``` #### Simply calling the blocks, no eval ```ruby Carburetor.search do |search| # `instance_eval` breaks the block/closure's normal scoping behavior # This works because we're allowing the block to behave normally, as # a closure. search.keywords params[:query] end ``` To be very clear, while I like Sunspot's syntax and prefer code that behaves in one (roughly) consistent way, there is _nothing wrong_ with the latter, more blocky form of this code. I do think it's uglier, in the objective sense that it has a lot of repetitive information that makes this code harder to read, especially as I add statements or nest multiple levels of blocks. I also think homemade muffins are uglier than the ones they have at Starbucks, but in that case I think it's clear that uglier is better.