On Tue, 2006-02-28 at 22:14 +0900, chiaro scuro wrote:
>  On 2/28/06, Ross Bamford <rossrt@[...].uk> wrote:
>  > This local variable isn't yet initialized (the n + 1 would be it's
>  > initializer), so n + 1 ends up being nil + 1, or (effectively) nil.+(1),
>  > hence the "undefined method '+' for nil:NilClass".
>  >
>  > Using self.n = 1 forces Ruby to treat the assignment as involving the
>  > method 'n' on 'self'.
>  >
>  > I don't think it's a bug, but I know it's tripped people (including me)
>  > up before. From the implementation point of view it's probably the
>  > lesser of two evils, though.
>  
>  It's really unrubesque and tricky.  What would be the consequences of
>  handling it as you would normally expect?  What would the side effects
>  be?
>  

This isn't necessarily based in fact (i.e. I've not surfed the source
just now) but I imagine it would be:

	* Harder to parse, with more ambiguous cases.
	* Generally slower, since local lookup would be 'the long way'
	  more often.
	* More difficult to follow the code six months down the line 
	  (or on the next guy's screen).

-- 
Ross Bamford - rosco@roscopeco.REMOVE.co.uk