eval behaves differently inside a method definition...

[timr]

#lets give strings the ability to evaluate theirselves as if in irb.look at me
=> nil

#good looks like strings can interpret theirselves. But how about this
case?
NameError: uninitialized constant Pumpkin
from (irb):287
from /usr/local/bin/irb:12:in `<main>'

#not flying. Is it a problem with the string? Try with eval of the
same string:
=> #<Pumpkin:0x109896c>

No problem evaluating the class definition in a string. So eval
behaves differently inside a method definition.

Could anyone please explain that?
Thanks in advance,
Tim

 

[Ehsanul Hoque]

Hi Tim.

#lets give strings the ability to evaluate theirselves as if in irb.
look at me
=3D> nil
=20
#good looks like strings can interpret theirselves. But how about this
case?
=20
NameError: uninitialized constant Pumpkin
from (irb):287
from /usr/local/bin/irb:12:in `<main>'
=20
#not flying. Is it a problem with the string? Try with eval of the
same string:
=20
=3D> #<Pumpkin:0x109896c>
=20
No problem evaluating the class definition in a string. So eval
behaves differently inside a method definition.

It's not that eval behaves differently inside a method definition. It's jus=
t that it takes into account the scope in which it was called.

When inside the String class=2C or any other class for that matter=2C if yo=
u create another class=2C you can't call it from outside the parent class w=
ithout referring to the parent. So for example:

class String
class Pumpkin
def pie
puts 'yum'
end
end
end
Pumpkin.new #=3D> NameError: uninitialized constant Pumpkin
String:umpkin.new #=3D> #<Pumpkin:0x109896c>

The parent class effectively acts as a namespace for the subclass. BTW=2C I=
really don't think I should call it a "subclass"=2C as that seems to imply=
inheritence - none of that here. Maybe someone else can tell us the proper=
name for this structure/pattern.

So you probably understand the issue by now=2C eval within the String class=
(whether or not inside a method definition) creates a "subclass" of sorts=
=2C and hence you can't call it directly outside. If you tried to call "Str=
ing:umpkin.new" instead after using your "irb" method=2C it would have wo=
rked (try it out). Alternately=2C you could have done it this way:

class String
def irb
eval self
end
end
"class :umpkin=3Bdef pie=3Bputs 'yum'=3Bend=3Bend".irb
Pumpkin.new.pie

Hope that helps.
- Ehsan
=20
_________________________________________________________________
Windows 7: It works the way you want. Learn more.
http://www.microsoft.com/Windows/windows-7/default.aspx?ocid=3DPID24727::T:=
WLMTAGL:ON:WL:en-US:WWL_WIN_evergreen:112009v2=

 

[timr]

The parent class effectively acts as a namespace for the subclass. BTW, Ireally don't think I should call it a "subclass", as that seems to imply inheritence - none of that here. Maybe someone else can tell us the proper name for this structure/pattern.
I understand--how about nested class or encapsulated class.

So you probably understand the issue by now, eval within the String class(whether or not inside a method definition) creates a "subclass" of sorts,and hence you can't call it directly outside. If you tried to call "String:umpkin.new" instead after using your "irb" method, it would have worked (try it out). Alternately, you could have done it this way:

class String
def irb
eval self
end
end
"class :umpkin;def pie;puts 'yum';end;end".irb
Pumpkin.new.pie

Hope that helps.
- Ehsan

Ehsan, nice explanation!
Hmmm. That means that you could make a binding to mainand add that to the eval argument to get it back to the main scope
where eval seems to work on anything:

class String
def irb
eval(self, SPECIAL_BINDING)
end
end

Now it should all work!yohoo
=> nilis totally awesome
=> nil
Mucho Gracias, amigo!!!
Tim

 

[Brian Candler]

There is the existing TOPLEVEL_BINDING constant you can use for this.
yum
=> nil

 

[timr]

Thank you Brian. Even better.

There is the existing TOPLEVEL_BINDING constant you can use for this.


yum
=> nil