From: Ilias Lazaridis <ilias@...>
Date: 2011-06-16T06:00:27+09:00
Subject: Re: CORE - Inconsistent Handling of Uninitialized Variables

On 15 Ιούν, 21:05, Michael Edgar <ad...@carboni.ca> wrote:
> 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.
[...] - (explanation)

You have company now, cause all this "breaks my brain", too.

I understand usually better by example, thus I focus on what I've
understood bye the code (and you explanation):

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

The code

> def foo(y)
>   if false
>     x = y

x is introduced (exists), but not yet assigned (value: nil)

>   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.

I understand this.

To simplify (and thus protect our brains), we discuss only locals/
globals

-

I understand the "set_local", and it works as expected.

def set_local(y)
  if false
    x = y
  end
  p x   #=> nil
  #p x2 #=> undefined
end
set_local(10)


def set_global(y)
  if false
    $x = y
  end
  p $x #=> nil
  p global_variables.include?(:$x) #=> true
  p $xx #=> nil
  p global_variables.include?(:$xx) #=> true

end
set_global(10)

-

I don't understand, why "p $xx" does not fail with and "not defined"
error.

Technically, the existence of the variable is observable all over the
program.

I don't see the reason why "$xx" is created and set to nil, instead of
throwing an "not defined" error (which I would expect when accessing
an undefined var, could be e.g. a typo of me).

Can this be demonstrated with code?

.

--
http://lazaridis.com