Forum: Ruby Issue with block and getting to local variables

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Tarek O. (Guest)
on 2008-11-12 22:33
Ok I'm new to ruby and want to do the following, I want to define a
function that is a ble to call a block and I want that block to have
access to the calling function's local variables. Also I'd like that
block of code to be attached to a variable so I can call it were and
when ever.

Thanks
Robert K. (Guest)
on 2008-11-12 22:55
(Received via mailing list)
On 12.11.2008 21:31, Tarek O. wrote:
> Also I'd like that
> block of code to be attached to a variable so I can call it were and
> when ever.

irb(main):001:0> bl = lambda {|a,b| puts a, b}
=> #<Proc:0x7ff98cf4@(irb):1>

 > Ok I'm new to ruby and want to do the following, I want to define a
 > function that is a ble to call a block and I want that block to have
 > access to the calling function's local variables.

irb(main):002:0> def fun
irb(main):003:1> x = 1
irb(main):004:1> y = 2
irb(main):005:1> yield x,y
irb(main):006:1> end
=> nil
irb(main):007:0> fun &bl
1
2
=> nil
irb(main):008:0>

Kind regards

  robert
Tarek O. (Guest)
on 2008-11-12 23:46
Robert K. wrote:
> On 12.11.2008 21:31, Tarek O. wrote:
>> Also I'd like that
>> block of code to be attached to a variable so I can call it were and
>> when ever.
>
> irb(main):001:0> bl = lambda {|a,b| puts a, b}
> => #<Proc:0x7ff98cf4@(irb):1>
>
>  > Ok I'm new to ruby and want to do the following, I want to define a
>  > function that is a ble to call a block and I want that block to have
>  > access to the calling function's local variables.
>
> irb(main):002:0> def fun
> irb(main):003:1> x = 1
> irb(main):004:1> y = 2
> irb(main):005:1> yield x,y
> irb(main):006:1> end
> => nil
> irb(main):007:0> fun &bl
> 1
> 2
> => nil
> irb(main):008:0>
>
> Kind regards
>
>   robert

Thank you Robert but the problem with that approach is the need to pass
the variables into the block (in this case x,y has to be passed in). I
wanted to avoid that because I would have ton of local variables that I
would have to pass in. Is there any way to do what I want?
Todd B. (Guest)
on 2008-11-13 00:50
(Received via mailing list)
On Wed, Nov 12, 2008 at 3:43 PM, Tarek O. <removed_email_address@domain.invalid>
wrote:
>>  > function that is a ble to call a block and I want that block to have
>> 2
> would have to pass in. Is there any way to do what I want?
x, y (and a, b) are objects.  They don't have to be integers.  They
could be arrays, hashes, etc.

Todd
Tarek O. (Guest)
on 2008-11-13 01:02
Todd B. wrote:
> On Wed, Nov 12, 2008 at 3:43 PM, Tarek O. <removed_email_address@domain.invalid>
> wrote:
>>>  > function that is a ble to call a block and I want that block to have
>>> 2
>> would have to pass in. Is there any way to do what I want?
> x, y (and a, b) are objects.  They don't have to be integers.  They
> could be arrays, hashes, etc.
>
> Todd

Yes I understand that. I dont want to have to do this because I dont
want to have to pass any variables:

yield x,y

i.e.) I want to know if there is a way to call the block such that it
knows or has access to all the local variables of the caller without
having to pass those local variables in.
Eric I. (Guest)
on 2008-11-13 05:50
(Received via mailing list)
On Nov 12, 5:59 pm, Tarek O. <removed_email_address@domain.invalid> wrote:

>
> i.e.) I want to know if there is a way to call the block such that it
> knows or has access to all the local variables of the caller without
> having to pass those local variables in.

Hi Tarek,

Yes, this is the standard behavior of blocks.  Blocks are closures,
which means that they have access to the surrounding environment.

For example, this code works just fine, even though "y" is a local
variable used set outside the block and used inside the block:

====

def method1(&block)
  0.upto(12) do |v|
    yield v
  end
end

def method2(y)
  method1 do |z|
    puts "#{y} * #{z} = #{y * z}"
  end
end

puts "Let's do the 3 times tables:"
method2(3)

====

I hope that helps,

Eric

====

Are you looking for on-site Ruby or Ruby on Rails training
that's been highly reviewed by former students?
http://LearnRuby.com
List R. (Guest)
on 2008-11-13 08:18
(Received via mailing list)
One thing with locals that got me is that you have to define them
first so the /parser?/ doesn't bail.

I.e

### breaks:
lamb = lambda { a+b }
a = 1
b = 2
p lamb.call


You must put a,b = nil,nil before the lambda definition :-/

( sorry for top post, on iphone just realized it, no clipboard )
Ara H. (Guest)
on 2008-11-13 08:39
(Received via mailing list)
On Nov 12, 2008, at 3:59 PM, Tarek O. wrote:

> i.e.) I want to know if there is a way to call the block such that it
> knows or has access to all the local variables of the caller without
> having to pass those local variables in.

block.call

this is just how blocks work - they enclose the scope from which they
were called

a @ http://codeforpeople.com/
Tarek O. (Guest)
on 2008-11-13 09:02
Hi and thanks to all for the help.

Can someone explain why this doesnt work

def foo
  x = 5
  yield
end

foo{puts x}


Q1) The only way to get it to work is to pass x into it when calling the
yield. Why is that, according to above the block does/should have access
to it because it is being called withing the scope of the variable

Q2) This is ultimately what I want to do (psuedo code below):

def my_function(&block)
  x = 5
  s = 15
  block.call
end

my_block = lamda{ puts "#{s+x}" }
my_function(&my_block)

But it complains about not knowing what s and x are, ie out of scope.
Why and how can this be resolved?
Sebastian H. (Guest)
on 2008-11-13 11:04
(Received via mailing list)
ara.t.howard wrote:
> this is just how blocks work - they enclose the scope from which they  
> were called

No, they don't. They enclose the scope from where they were created.
def foo(&block)
  bar = 5
  block.call
end
will NOT make bar accessible within the block.
You can't do that. Best you can do is block.call(binding) and then get
the
variables from the binding object using eval in the block, but don't do
that.

HTH,
Sebastian
Brian C. (Guest)
on 2008-11-13 12:34
Tarek O. wrote:
> Q2) This is ultimately what I want to do (psuedo code below):
>
> def my_function(&block)
>   x = 5
>   s = 15
>   block.call
> end
>
> my_block = lamda{ puts "#{s+x}" }
> my_function(&my_block)
>
> But it complains about not knowing what s and x are, ie out of scope.
> Why and how can this be resolved?

Turn it around:

  def my_function(&block)
    x = 5
    s = 15
    block.call(x,s)
  end

  my_block = lambda { |x,s| puts "#{s+x}" }
  my_function(&my_block)

This is a clean solution. my_block is a genuine function - it accepts
arguments, and returns a result.

It is possible for my_block to have access to local variables defined
within its own scope. But it's hard for it to have access to local
variables which didn't exist at the time it was created. 'def' and
'class' start their own clean scopes.

An alternative approach is using instance variables and objects, but you
may need to use instance_eval to set the context within which the
instance variables are looked up.

class MyClass
  def initialize(x=5, s=15)
    @x = x
    @s = s
  end
  def my_function(&blk)
    instance_eval(&blk)
  end
end

obj = MyClass.new
my_block = lambda { puts "#{@s+@x}" }
obj.my_function(&my_block)

But that any method calls in the lambda will also be calls to MyClass
methods, not to methods defined on the 'main' object.
Robert K. (Guest)
on 2008-11-14 09:35
(Received via mailing list)
On 13.11.2008 04:47, Eric I. wrote:
> On Nov 12, 5:59 pm, Tarek O. <removed_email_address@domain.invalid> wrote:
>
>> i.e.) I want to know if there is a way to call the block such that it
>> knows or has access to all the local variables of the caller without
>> having to pass those local variables in.
>
> Yes, this is the standard behavior of blocks.  Blocks are closures,
> which means that they have access to the surrounding environment.

I believe with "caller" OP means the method that invokes the block.  Not
the bit of code where the block is defined (variable "v" in your
example).  And the local variables defined in the method invoking the
block are *invisible* to the block unless, of course, the method
invoking and defining the block is the same as in

def f
   x = 10
   b = lambda { puts x }
   b.call
end

Kind regards

  robert
This topic is locked and can not be replied to.