Calling a block with parameters in a new scope

Ruby
1

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.

2

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.

3

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

4

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

5

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

eigenclass.org

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

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

Cheers
Robert