From: Yukihiro Matsumoto <matz@...>
Date: 2006-03-02T16:29:50+09:00
Subject: Re: Subclassing Struct.new

Hi,

In message "Re: Subclassing Struct.new"
    on Thu, 2 Mar 2006 11:34:20 +0900, "Caleb Clausen" <vikkous@gmail.com> writes:

|So, then, what will you do with this:
|
|def foo
|   bar %(
|      bar=1
|   )
|end
|
|Should the first bar be a variable or method? If you assume it's a
|method initially, the rest looks like a string, and there's no
|apparent assignment in the rest of the method to clue the parser in
|that it needs to go back and make it a variable instead. Granted, this
|example is pathological, but I think there might be less pathological
|cases that have the same problem.

Hmm, you make me remember a trick in the parser (which I made).

|I think that the current rule that local variables are declared on
|first assignment is a good one. Yes, it leads to confusion in a few
|cases, mostly for those who aren't aware that this is one of ruby's
|few gotchas. But Ruby is hard enough to parse now; I need to look an
|arbitrary number of tokens into the past to determine if a name is a
|local var or not. I'd rather not have to look an arbitrary number of
|tokens into the future(!) as well. Especially as there seems to be
|little need for this new feature. (Unassigned locals will (presumably)
|always be nil before the first assignment anyway; why would you want
|to use a variable before its first (lexical) assignment? Your example
|with the local variable in a block didn't seem to address that
|question.)

My original intention is _not_ to use local variables before their
first assignment, but to extent their scope to by their outer most
appearance in the method.  But at the same time, I expect the new rule
to solve

   print foo if foo = bar()

problem.  I will ponder the new rule (and implementation) bit more.

							matz.