From: Michael Edgar <adgar@...>
Date: 2011-06-16T03:05:39+09:00
Subject: Re: CORE - Inconsistent Handling of Uninitialized Variables

On Jun 15, 2011, at 1:50 PM, Ilias Lazaridis wrote:

> Is this a defect or is there an explanation for this behaviour?


I can speak to local variables; class variables still break my brain a little.

Local variables are created during parsing and initialized to nil when they
are first encountered. They are available for use at any point in the same
scope lexically after their initialization.

This is done because if you attempt to read a local variable lexically before it has
been introduced in a local context, we can be sure you have made an error.

For global variables and instance variables, we cannot have such lexical
guarantees. While it may be obvious within the scope of a simple program
that a global or ivar has not yet been introduced, it is not a local property.
Thus, access is permitted; if the variable has not been initialized, then it
is initialized to nil.

The same occurs when Ruby sees an introduced, but uninitialized, local
variable:

def foo(y)
  if false
    x = y
  end
  p x
end
foo(10)

#=> nil

The local is seen at "x = y", created in the local variable table, and initialized
to nil. The reference to "x" later succeeds because the local has been created,
though never initialized.

Michael Edgar
adgar@carboni.ca
http://carboni.ca/