Calling a block with parameters in a new scope

Calling a block in a new scope is easy enough:

self.instance_eval &block

And calling a block, passing it parameters is easy enough:

block.call(*params)

But is there some way to do both? To both change the scope of evaluation
and pass variables into the block.

Ruby T. wrote:

Calling a block in a new scope is easy enough:

self.instance_eval &block

And calling a block, passing it parameters is easy enough:

block.call(*params)

But is there some way to do both? To both change the scope of evaluation
and pass variables into the block.

Hello,

I’m not sure I fully understand the question being asked here. Can you
provide a small bit of code to highlight what you are trying to acheive.

Do you wish to pass vaiables into the instance_eval block?

Any variables in scope when the instance_eval block is called can be
used in the instance_eval block itself. However, if you were to pass a
proc object into the instance_eval it would retain the context it was
created at.

See below for an example of this.

class Test
def initialize(arg)
@instance_variable = arg
end
end

test_obj = Test.new(“initializing_arg”)

outside = “outside instance_eval”

proc = Proc.new {|arg| puts self} #self main here

test_obj.instance_eval do
puts @instance_variable #test_obj instance variable.
puts outside #any variable from outside the block can be passed in.
puts proc #will return main rather than the object
end

Hmm, I get the feeling I have ranted about stuff that does not help you
one bit with your question…

Get back to me with a bit more detail and hopefully I’ll be able to
help!

Cheers,

Matt.

Matt G. wrote:

Ruby T. wrote:

Calling a block in a new scope is easy enough:

self.instance_eval &block

And calling a block, passing it parameters is easy enough:

block.call(*params)

But is there some way to do both? To both change the scope of evaluation
and pass variables into the block.

Hello,

I’m not sure I fully understand the question being asked here. Can you
provide a small bit of code to highlight what you are trying to acheive.

Do you wish to pass vaiables into the instance_eval block?

Any variables in scope when the instance_eval block is called can be
used in the instance_eval block itself. However, if you were to pass a
proc object into the instance_eval it would retain the context it was
created at.

See below for an example of this.

class Test
def initialize(arg)
@instance_variable = arg
end
end

test_obj = Test.new(“initializing_arg”)

outside = “outside instance_eval”

proc = Proc.new {|arg| puts self} #self main here

test_obj.instance_eval do
puts @instance_variable #test_obj instance variable.
puts outside #any variable from outside the block can be passed in.
puts proc #will return main rather than the object
end

Hmm, I get the feeling I have ranted about stuff that does not help you
one bit with your question…

Get back to me with a bit more detail and hopefully I’ll be able to
help!

Cheers,

Matt.

Oops, that last ‘puts proc’ should be proc.call(“whatever”)

If full:

class Test
def initialize(arg)
@instance_variable = arg
end
end

test_obj = Test.new(“initializing_arg”)

outside = “outside instance_eval”

proc = Proc.new {|arg| puts self} #self main here

test_obj.instance_eval do
puts @instance_variable #test_obj instance variable.
puts outside #any variable from outside the block can be passed in.
proc.call(“whatever”) #will return main rather than the object
end

On May 19, 10:07 pm, Ruby T. [email protected] wrote:

self.instance_eval &block

And calling a block, passing it parameters is easy enough:

block.call(*params)

But is there some way to do both? To both change the scope of evaluation
and pass variables into the block.

http://eigenclass.org/hiki.rb?instance_exec

On 5/20/07, Phrogz [email protected] wrote:

http://eigenclass.org/hiki.rb?instance_exec

OP We have just discussed this twice recently, maybe you should browse
the recent posts…

Phrogz: Your link seems outdated,
c.f.http://eigenclass.org/hiki/bounded+space+instance_exec
for a discussion of #undef_method (bad) vs. #remove_method (good) and
please note the potential danger of endless recursion.

Cheers
Robert

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs