|
|
|
|
||||||
![]() |
|
|
LinkBack | Outils de la discussion |
|
|
#1 |
|
Messages: n/a
Hébergeur: |
Dear rubyists,
i'm fairly new to ruby, so please apologize if i'm missing something obvious. I'm trying to figure out how constant lookup works and find myself confused. Here we go: class A; C=3 end $a = A.new $a.instance_eval "C" # => 3 $a.instance_eval {C} # ~> NameError: uninitialized constant C [...] This is ruby 1.8.6. My naive mental model of what's happening: constants are evaluated statically before the block is passed along, and wrapping it up as a string prevents the interpreter from looking inside too early. :-) That seems to have changed with Ruby 1.9 (yesterday's trunk), but there are a few surprises still: def a_eval(&block) $a.instance_eval(&block) end $a.instance_eval {C} # => 3 a_eval {C} # ~> NameError: uninitialized constant C [...] a_eval {instance_eval {C}} # => 3 -- ??? I gather it's a binding issue, but why should the binding of constants (of anything, really) differ between inside "self.instance_eval { ... }" and outside? a_eval {binding}.eval("C") # ~> NameError: uninitialized constant C [...] a_eval {instance_eval{binding}}.eval("C") # => 3 $a.instance_eval {binding}.eval("C") # => 3 Can anybody shed some light on this? Thanks a lot! Kind regards, achim -- Posted via http://www.ruby-forum.com/. |
|
|
|
#2 |
|
Messages: n/a
Hébergeur: |
Achim Passen wrote:
> Dear rubyists, > > i'm fairly new to ruby, so please apologize if i'm missing something > obvious. I'm trying to figure out how constant lookup works and find > myself confused. Here we go: > > class A; C=3 end > > $a = A.new > $a.instance_eval "C" # => 3 > $a.instance_eval {C} > # ~> NameError: uninitialized constant C [...] > > Can anybody shed some light on this? Thanks a lot! > > Kind regards, > achim class A C=3 end $a = A.new $a.instance_eval "C" #=> 3 $a.instance_eval {C} # ~> NameError: uninitialized constant C [...] Its not being called properly for 1.8 instead use this... $a.instance_eval {A::C} A being the class, and C being the constant. Regards, - Mac -- Posted via http://www.ruby-forum.com/. |
|
|
|
#3 |
|
Messages: n/a
Hébergeur: |
Achim Passen wrote: > I'm trying to figure out how constant lookup works [...] > > class A; C=3 end > > $a = A.new > $a.instance_eval "C" # => 3 > $a.instance_eval {C} > # ~> NameError: uninitialized constant C [...] That's an interesting question! Michael Linfield already gave an "answer", but I think I have another one. Look here: class A C=3 def prt_C p C end end a = A.new def a.another_prt_C p C end a.prt_C # OK! a.another_prt_C # fails! the 'another_prt_C' method fails to see the constant. I have the book 'The Ruby Programming Language' and it has a page about 'Constant Lookup'. That page explains that "ruby attempts to resolve a constant reference in the *lexical* scope of the reference. This means that it first checks the class or module that encloses the constant reference." In other words, since our class A doesn't enclose the 'another_prt_C' method, this method can't reference the constant (directly). "Lexical" means textual. That page also continues to explain that if the lookup fails, ruby checks the class hierarchy as well. But the wording of the book here is vague and there's roon for interpretation that 'another_prt_C' indeed shouldn't work and that it's not a bug. That's why you shouldn't expect instance_eval to see 'C': because this constant isn't defined in a class or module *lexically enclosing* your block. You say it's fixed in 1.9. It probably means that 'another_prt_C' too works in 1.9, or else my nice theory should be garbage collected! If it does work in 1.9, I guess what they fixed is the section I said was vague. -- Posted via http://www.ruby-forum.com/. |
|
![]() |
| Outils de la discussion | |
|
|