John W. Long wrote:
> Jamey Cribbs wrote:
>> The way it works is that in the Plane.find method, I grab the block 
>> and pass it to #instance_eval.  This executes the block in the Plane 
>> classes environment, so it knows that when it sees the attribute 
>> "speed" or "country" in the block, it knows to call Plane.speed and 
>> Plane.country.  Planes.speed happens to be a reference to a 
>> SkiplistColumn instance and it knows how to handle the "> 350" passed 
>> to it.
>
> The problem with this approach is that you loose access to instance 
> variables. For instance:
>
>   >> class Object
>   >>   def with(&block)
>   >>     instance_eval(&block)
>   >>   end
>   >> end
>   => nil
>   >> @test = 1
>   => 1
>   >> Object.new.with { puts @test }
>   => nil
>
> In the above example @test when used within the context of the with 
> block is thought to be an instance variable of the object, which is 
> why it returns nil instead of 1. I consider this behavior undesirable.
Hmm, I see your point.  I've been playing around with this all morning, 
but I can't see a way out of this except to go back to passing the Table 
class to the query block and also qualifying the table column names in 
the block.

Even though it does clutter up the query block more, I think John is 
right that it is definitely more important to have access to the 
instance variables in the calling object.

Thanks for pointing this out to me, John.

Jamey