Hi,

7stud -- wrote:
> David A. Black wrote:

> As p. 329 in pickaxe2 carefully explains, it is a ruby parsing rule that 
> determines what x means.  As I read the rule, and as Daniel explains, 
> and as the two examples show(the 'a' example and the 'x' example), the 
> rule is: if there is any code that has x=val on a line before the use of 
> x, then x will be interpreted as a variable.  If there is no assignment 
> to x on a line higher in the code, then x will be interpreted as a 
> method call.

Please, look at this 2 examples of "parse-time":
1)
> pp ParseTree.translate('bar = 3
define_method(:foo) do
  bar
end')
[:block,
 [:lasgn, :bar, [:lit, 3]],
 [:iter, [:fcall, :define_method, [:array, [:lit, :foo]]], nil, [:lvar, 
:bar]]]

2)
> pp ParseTree.translate('bar = 3
def foo
  bar
end')
[:block,
 [:lasgn, :bar, [:lit, 3]],
 [:defn, :foo, [:scope, [:block, [:args], [:vcall, :bar]]]]]

***
In 1) we see a :lvar node, whereas in 2) we see a :vcall. From my 
interpretation of p.329 of pickaxe2 i do not agree with the 2nd case 
(but probably it's my problem - comment please). In the 2nd case, IMHO, 
we should see a lvar node.
This may seem a detail, but i was bitten by that a few minutes ago. Let 
me show a simplified example:

bar = "test"
c = Class.new
c.class_eval do
  def foo
    bar
  end
end
> c.new.foo
NameError: undefined local variable or method `bar'
# i was expecting to get "test"

The (hack) "solution" (it's a hack because IMHO i shouldn't have to do 
that):
bar = "test"
c = Class.new
c.class_eval do
  define_method(:foo) do
    bar
  end
end
> c.new.foo
"test"

Note: only one more thing, since ruby 1.8 have a "problem" with block 
(it can't get other blocks - &block in argument) this could be a 
problem. I know you can hack these thing through a method - but that's 
another hack :P... too much hacks for me :-)

I would appreciate very much all your comments about the current 
behavior of ruby (1.8).

Regards,
Vasco Andrade e Silva
-- 
Posted via http://www.ruby-forum.com/.