3. Metaprogramming patterns - 20 kyu. Closures

In the previous post, we touched on the most important concept - closure.

The essence of this concept is that in any block it seems to be “the whole world around us” as it is seen in the context where the block is created. It is more correct to say that the block does not include the entire world around (name space), but a point of view on the world around (name space) is fixed.





Re-read this paragraph again after considering the following examples.



To understand the examples, it is useful to get acquainted with the concept of a block, Proc#call Proc#call , the lambda construct, as well as the concepts of a class instance variable (instances variables are variables whose names begin with the dog) and class variables (class variables are variables whose names begin with two dogs):

• Proc Proc - class for blocks that can be called unnamed (anonymous) methods that can be created directly in expressions;
• The b.call(*args) expression executes b , and returns the result of the execution; instead of call you can use square brackets.
• lambda {|a,...| ... } lambda {|a,...| ... } - creates a block, for example b = lambda {|x,y,z| x+y+z} b = lambda {|x,y,z| x+y+z} will create a block that adds three numbers, in particular, the expression b[1,2,3] will return 6 ;
• blocks are not only created using lambda, they are also constructed automatically when the method is called, followed by the { ... } or do ... end ; for example ary.inject{|a,b| a * b} ary.inject{|a,b| a * b} will pass inside the inject method a block that multiplies two numbers;
• Instance variables live in objects and are considered to be initialized to the default value nil;
• class variables live in classes and are considered uninitialized by default; when they are used in an expression without prior initialization, an Exception “ uninitialized class variable .. in ... ” occurs;

So, code samples:

')

Example 1

a = 1 <br>

b = lambda { puts a }<br>

b.call # 1 <br>

a = 2 <br>

b.call # 2 <br>

# - <br>



Example 2

class Abc <br>

attr_accessor :bar <br>

def foo <br>

@bar ||= 0 <br>

x = 5 <br>

lambda { puts @bar , x, self .class; }<br>

end <br>

end <br>

<br>

x = 10 <br>

a = Abc .new<br>

b = a.foo<br>

b.call # 0, 5 Abc <br>

a.bar += 1 <br>

x = 10 <br>

b.call # 1, 5, Abc <br>

# bar a b, <br>

# ( ) -- <br>

# ; - <br>

# foo, @a x, <br>

# , <br>

# , foo . <br>

<br>



A closure occurs for any block, whether created with lambda or with a block passed to the method, either with braces or with a do ... end construct.



In the last example, we called the foo method on the instance a of some class Abc .

Inside this method, the instance variable @bar and a block is returned, which

prints this variable as well as the value of the local variable x and self.class .

After executing this code, you will see how strongly the unit is tied to its homeland, all its thoughts and motivations are there.



In the context in which the string " b.call " is b.call , the @bar variable @bar not visible (or rather, it simply does not exist in this context).

Nevertheless, the execution of the b block leads to the output of the variable @bar object a , which, as it were, is not suitable here. This is explained by the fact that the block was created in the context of the execution of the foo method of the object a , and in this context all the instance variables of the object a were visible.



Thus, the internal context of an object can be pulled out with the help of a block created inside the object and transferred as the result of a certain function to the outside.



Example 3

class Abc <br>

attr_accessor :block <br>

def do_it <br>

@a = 1 <br>

block.call<br>

end <br>

end <br>

<br>

c = 1 <br>

a = Abc .new<br>

a.block = lambda { puts " c= #{ c } " }<br>

a.do_it # 1; <br>

# - <br>

# <br>

<br>

a.block = lambda { puts " @a= #{ @a .inspect } " }<br>

a.do_it # nil, .. @ , <br>

# " " a.block. <br>

# a.block Abc#foo <br>

# Abc#foo a.block <br>





Repeat the same thing, only now the block will be created simply as a block associated with the method, and not with the lambda construction:

class Abc <br>

def do_it (&block)<br>

@a = 1 <br>

block.call<br>

end <br>

end <br>

<br>

c = 1 <br>

a = Abc .new<br>

a.do_it {puts " c= #{ c } " } <br>

a.do_it { puts " @a= #{ @a .inspect } " }<br>

<br>



What is context?

This is a definite point of view on the namespace, from which something is visible, something is invisible, but something is seen in its own way.



For example, instance-variables of the object for which this method is visible and self equal to this object are visible from the body of the method. Instance variables of other objects are not visible.



It is useful to consider the particular expression self as some method that can be defined in its own way in each context.



The reason for changing the context is the def and class constructs. They usually lead to a change in the visibility of the instance variables, class variables and a change in the value of the expression self .



A regular block is also a new context, even if it includes the context in which it was created. A block can have its own local variables (as well as in C) and arguments (which should be interpreted as special local variables).



Actually the concept of context has its very specific mapping in Ruby - this is an object of class Binding Binding Each block has a binding , and this binding can be passed as the second argument to the eval method: “run this code in this context”:



Example 4

class Abc <br>

attr_accessor :x <br>

def inner_block <br>

lambda {| x | x * @factor }<br>

end <br>

end <br>

<br>

a = Abc .new<br>

b = a.inner_block<br>

eval ( " @factor = 7 " , b.binding)<br>

puts b[ 10 ] # 70 <br>

eval ( " @x = 6 * @factor " , b.binding)<br>

puts ax # 42





But, of course, you don’t need to write like that. To execute code in the context of an object, simply use instance_eval :



Example 5

class Abc <br>

attr_accessor :x <br>

end <br>

<br>

a = Abc .new<br>

a.instance_eval( " @factor = 7 " )<br>

a.instance_eval( " @x = 6 * @factor " )<br>

puts ax # 42





Paycheck

For such pleasure as closures, you have to pay.

• If a link to a block is alive, then the corresponding context is alive and all objects that are visible from this context are alive (first of all, it means local variables). So we have no right to collect these objects by the garbage collector. The closure as it hooked them all at once. For those who are familiar with the concept of smart pointers, it can be clarified that creating a context (binding) results in an increase in ref_counter by 1 for all visible objects, and accordingly when the context is destroyed (which occurs when all blocks created in this context are deleted) the ref_counter decrease by 1 for all visible objects. But in reality this is not done. Ruby's garbage collector is built on a different concept than smart pointers (see Status of copy-on-write friendly garbage collector - Ruby Forum , in particular, www.ruby-forum.com/attachment/2925/mostlycopy-en.ppt , and also Memory leak in callcc )
• Real closures store not only the appearance of a namespace, but also a stack of calls. In Ruby, you can access the stack, which means that if we want to achieve the absolute authenticity of an instantiated context (a Binding class object) to the concept of a real context, we need to store both the call stack and all objects that are in this stack, and this becomes a real problem. Example of access to the call stack:
  
  
  
  def backtrace <br>

begin <br>

raise Exception .new( '' )<br>

rescue Exception =>e<br>

e.backtrace[ 1 ..- 1 ]<br>

end <br>

end <br>

<br>

def f <br>

g<br>

end <br>

<br>

def g <br>

puts backtrace.join( " \n " )<br>

end <br>

<br>

f<br>

<br>


  
  As a result, you get the output:

   make_rescued.rb: 15: in `g '
   make_rescued.rb: 11: in `f '
   make_rescued.rb: 18
  

• One of the optimizations may be that the block code is analyzed and the context is not created if the block does not use local variables, etc. For example, for expressions of the type ary.map{|i| i*i} ary.map{|i| i*i} or users.map{|u| e.email} users.map{|u| e.email} , I would not want to deal with closures. But often it is simply not possible to predict that from the visible namespace will be used by the block, since, in principle, an eval or a method call with an associated block, which, in turn, can request the block.binding value passed to it, can occur in a block . do with him what he wants. You should also be afraid of the send(m, *args) expression, since this can be send('eval', *args) . It is possible to create a block with a minimal context as follows: " block = class << Object.new; lambda { ... } end ". Perhaps it makes sense to optimize (first of all I want to get rid of the call stack clinging to the closures) to come up with a new language construct like glob_do ... end to create blocks whose general context is a global context in which self is equal to the special main object.

Links

• www.javapassion.com/rubyonrails/ruby_meta.pdf - the presentation indicates a lot of things that I am going to write about in this blog.
• www.infoq.com/presentations/nutter-jruby-jvm-lang-summit - The Pain of Bringing an Off-Platform Dynamic Language for the JVM - talks about the problems of writing a compiler in Java byte-code for dynamic languages, gives a general idea about tasks solved when writing interpreters dynamic languages
• 1. Metaprogramming patterns - 25 kyu. Eval method
• 2. Metaprogramming patterns - 22yu. Reuse in small - bang!