From: Just Another Victim of the Ambient Morality <ihatespam@...>
Date: 2007-09-24T11:05:04+09:00
Subject: Re: Weird variable scope behaviour...


"7stud --" <dolgun@excite.com> wrote in message 
news:c84036c062811fa759eb9e680dfd75a6@ruby-forum.com...
> 7stud -- wrote:
>> Does the following not work as you would
>> expect:
>>
>>
>> if false
>>     x = 10
>> end
>>
>> if x
>>     puts "yep"
>> else
>>     puts "nope"
>> end
>>
>
> Ah.  I see what you are concerned about:
>
> if y
>    puts "yep"
> else
>    puts "nope"
> end
>
> undefined local variable or method `y' for main:Object (NameError)

    I'm not sure, exactly, what I'm concerned about but I can give you some 
clues.
    It's a little weird that the above code with variable y results in a 
name error but the previous example with variable x simply results in a nil 
object reference.  It seems as if they should both result in a nil object 
reference or they should both result in a name error, rather than being 
inconsistent with each other.
    The most pragmatic example of a problem, that I can think of, is a 
situation where you have a bug that's immediately caused by a variable 
that's unexpectedly nil.  Now, you have to trace back the life of the 
variable, which can traverse many different scopes, to hopefully discover 
that there was an execution path that didn't initialize the variable. 
Instead, wouldn't it have been nice if the interpreter simply told you, at 
the variable's first use, that it didn't exist 'cause it wasn't initialized?
    Now that I put it this way, I think I see how its current behaviour is 
an implementation detail, done for increasing speed, leaking through the 
interface...