Phlip wrote:
>>>> You gotta use Ripper to convert the block to opcodes, then eval 
>>>> them  one by one.
>>> dude - that is *hardcore*  ;-)
> 
> Who was just fussing about "too many lines of code in the framework"?
> 
>>   2. The facilities needed to implement this kind of reflection
>>      should be part of ruby core.
> 
> Right:
> 
>   report = journal do
>              my_code()
>            end
> 
> Inside journal{}, everything the Ruby VM does gets packed into a report. 
> Then you rip the report to get back to your details. That's what assert{ 
> 2.0 } _can't_ do, so it goes in two passes.
> 
> The first pass is a normal block.call, to detect success or failure. 
> This is so any bugs in the second pass don't throw the test run.
> 
> The second pass puts the block into Ripper to decompile it, and then the 
> fun starts.

So you have to be careful in the block to avoid side effects, right? 
Otherwise pass1 and pass2 might start with different state.

-- 
       vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407