Ryan Davis wrote:
> On Mar 1, 2010, at 00:32 , Nick Sabalausky wrote:
> 
>>      File.unlink destent.path if remove_destination && 
>> Why does it do that, and how can I fix it?
> I have no idea because there is no test to look at that reproduces this 
> problem. So, write a failing test and make it work. This would be 
> especially easy if you refactored that File.unlink to be a method of 
> Entry_ (don't name it that. ugh!).

Ok, I've done a simplified test:

-----------------------
def callWith123 &dg
  puts "dg.call(1) returns #{dg.call(1)}"
  puts "dg.call(2) returns #{dg.call(2)}"
  puts "dg.call(3) returns #{dg.call(3)}"
end

def testIt
  puts "Entering testIt"
  callWith123 do |value|
    if value == 2 then
      return false
    end
    true
  end
  puts "Leaving testIt"
end

puts "Start"
testIt
puts "End"
-----------------------

What I expected:

-----------------------
Start
Entering testIt
dg.call(1) returns true
dg.call(2) returns false
dg.call(3) returns true
Leaving testIt
End
-----------------------

What I got:

-----------------------
Start
Entering testIt
dg.call(1) returns true
End
-----------------------

Apparently, the "return false" returns from testIt instead of merely 
returning from the delegate. So it turns out that when you do something 
like this:

-----------------------
def foo &dg
  #stuff here
end

foo do |value|
  #stuff here
end
-----------------------

That "do |value|...end" is *not* a full function literal like I was 
expecting it to be, but some kind of...like a closure of a portion of 
the function it's contained in. More like using cross-function goto's 
than calling a passed-in function.

So the cp_rx function I posted *does* work right, it was just that the 
filter I was passing in to it was malformed and returning from the top 
few entires in the call stack instead of just the top one.
-- 
Posted via http://www.ruby-forum.com/.