Por defecto, IRB siempre “escupirá” el valor resultante de evaluar la expresión introducida por el usuario. Aunque la mayoría de las veces eso está bien, hay otras en las que sacarias el corazón con una cucharilla de Té  a quien tuvieras delante por la crispación que produce esta “verbosidad”.

Me refiero a situaciones del tipo “quiero recorrer un array y listar el nombre de sus elementos con puts”, ejemplo:

ArrayEnorme.each do |element| puts "#{element.name}\n" end

Con el código anterior vamos a mostrar el nombre de cada elemento del Array. Hasta aquí todo normal. El problema de evaluar esto en IRB es que, si ArrayEnorme tiene bastantes elementos y cada elemento tiene bastantes atributos, las lineas que imprimos con el nombre de cada elemento quedaran “sepultadas” por un montón de datos inutiles. Es decir, si el buffer de nuestra consola no se ha llenado con estos datos inutiles (perdiendo así las lineas con el nombre de cada elemento) tendremos que hacer scroll ad-infinitum, que para el caso es casí como si se hubierán perdido.

Para evitar esto, os presento mi solución de andar por casa:

def toggle_output
context.return_format == "Output canceled\n" ? IRB.conf[:PROMPT][context.prompt_mode][:RETURN] : context.return_format = "Output canceled\n"
end

alias tgo toggle_output

Después de copiar las lineas anteriores en nuestro .irbrc podemos hacer pruebas:

madtrick::madtrick::$irb
irb(main):001:0> 2 + 1
=> 3
irb(main):002:0> toggle_output
Output canceled
irb(main):003:0> 2 + 1
Output canceled
irb(main):004:0> toggle_output
=> "=> %s\n"
irb(main):005:0> 2 + 1
=> 3

Y voila, ya podemos callar y dar voz a IRB cuando nos plazca.

El concepto que implementa sketches es sencillo: las modificicaciones que hagamos en nuestro editor de texto, se reflejan al instante en la sesión de irb. Es decir, si en el editor de texto creamos una clase y guardamos los cambios, la clase estará disponible automaticamente en la sesión de irb.

Su utilización es sencilla: arrancamos el IRB y lanzamos nuestro editor favorito con el comando sketch. A partir de ahí, el funcionamiento es como expliqué antes.

Mola : )

En el rdoc nos encontramos con la siguiente definición:

callcc {|cont| block } => obj

Generates a Continuation object, which it passes to the associated block. Performing a cont.call will cause the callcc to return (as will falling through the end of the block). The value returned by the callcc is the value of the block, or the value passed to cont.call. See class Continuation for more details. Also see Kernel::throw for an alternative mechanism for unwinding a call stack.

Un tanto críptico, ¿No?. Basicamente, callcc almacena la dirección de memoria y el contexto (en un objeto Continuation) de donde se le llamo. Sigue siendo raro,¿No?

Mejor un ejemplo. Sea el siguiente metodo:

 
counter = 0
 
def foo
exit if callcc{|$cont| } == 3
puts "hello world"
end
 
foo
 
$cont.call(counter += 1)

(Si ya se que las variables globales son malignas : ( )

Ejecutando el ejemplo:

madtrick::madtrick::$ruby test3.rb
hello world
hello world
hello world

Como se puede apreciar, se imprimen tres “hello world” con sólo una llamada al método foo.

¿Qué podemos extraer del ejemplo anterior?

• Cada llamada a la continuación ($cont) nos vuelve a llevar a linea donde se definió.
• Si en la llamada a la continuación pasamos algun parámetro, este es devuelto por callcc

Tambien podríamos utilizar los ejemplos del post anterior (Tail Call Optimization) para explicar el funcionamiento de callcc:

Calculo del factorial de un número:

class TCOTest
  # tail-recursive factorial
  def fact( n, acc = 1 )
    if n < 2 then
      acc
    else
       fact( n-1, n*acc ) 
    end
  end
 
  def fact_cc( n, acc = 1 )
    cont = callcc{|cont| cont}
    if n < 2 then
      acc
    else
       n, acc = n-1, n*acc
       cont.call cont 
    end
  end
 
  # length of factorial
  def fact_size( n )
    fact( n ).size
  rescue
    $!
  end
 
 
  # length of factorial
  def fact_size_cc( n )
    fact_cc( n ).size
  rescue
    $!
  end  
end

Si lo probamos en el irb vemos que fact_size_cc no da ningún tipo de problema mientras que la función fact_size (sí, por carecer Ruby de TCO) ya que nos quedamos sin espacio en la stack.

...
irb(main):009:0> t.fact_size 10000
=> #<SystemStackError: stack level too deep>
irb(main):010:0> t.fact_size_cc 10000
=> 14808

El otro ejemplo del post anterior, la función de Fibonacci:

En el ejemplo anterior, utilizábamos la palabra reservada redo junto con un método definido ad-hoc para poder realizar el cálculo:

  define_method(:acc) do |i, n, result|
    if i == -1
      result
    else
      i, n, result = i - 1, n + result, n
      redo
    end
 
def fib_redo(i)
   acc i,1,0
end

Pero tambien se podria haber hecho de esta otra forma:

def fib_call_cc(i, n = 1, result = 0)
  cont = callcc{|cont| cont}
  if i == -1
    result
  else
    i, n, result = i - 1, n + result, n
    cont.call cont
  end
end

En el ejemplo anterior se puede apreciar como el contexto se mantiene. En este caso para los valores i,n y result.

Si ejecutamos un simple benchmark (para n en 50000) para comparar redo vs callcc, obtenemos los siguiente:

 
madtrick::madtrick::$ruby test.rb 
Time for fib_redo:      0.390000   0.010000   0.400000 (  0.403986)
Time for fib_call_cc:   0.500000   0.000000   0.500000 (  0.519504)

redo ( 0.403986) es un poco más rápido que callcc ( 0.519504). Echándole un vistazo rapido al codigo de la máquina virtual de Ruby se entiende rápidamente el porque. redo esta implentado utilizando goto’s mientras que callcc es una llamada a una función que se encarga de guardar toda la información necesaria en un objeto Continuation, por lo que necesita más tiempo.

Para mas información sobre callcc, su funcionamiento y los continuations:

• Continuations
• Callcc
• Setjmp/longjmp, funciones en C con las que se puede implementar un comportamiento similar

En esta pagina lo explican bastante bien (entre otros tipos de recursividad), pero basicamente una función tail-recursive es aquella que no tiene ninguna operación pendiente de ejecutar tras la llamada recursiva. En estas funciones, la llamada recursiva puede ser substituida simplemente por un salto al comienzo de la función que se llama, con lo que se ahorra espacio en el stack. De esto ultimo se encarga el compilador y es lo que se conoce como Tail Call Optimization (TCO a partir de ahora).

Así que aparentemente la TCO mola, ¿No?

El problema es que Ruby no tiene implementada TCO en su maquina virtual con lo que independientemente de como estructuremos nuestras funciones recursivas, siempre estaremos limitados por el tamaño de nuestra Stack.

Pero siempre hay solución para todo y con Ruby, más. En ésta página dan dos soluciones para tener una pseudo-TCO.

Copio y pego la primera solución:

class Class
  # Sweet stuff!
  def tailcall_optimize( *methods )
    methods.each do |meth|
      org = instance_method( meth )
      define_method( meth ) do |*args|
        if Thread.current[ meth ]
          throw( :recurse, args )
        else
          Thread.current[ meth ] = org.bind( self )
          result = catch( :done ) do
            loop do
              args = catch( :recurse ) do
                throw( :done, Thread.current[ meth ].call( *args ) )
              end
            end
          end
          Thread.current[ meth ] = nil
          result
        end
      end
    end
  end
end
 
class TCOTest
  # tail-recursive factorial
  def fact( n, acc = 1 )
    if n < 2 then acc else fact( n-1, n*acc ) end
  end
 
  # length of factorial
  def fact_size( n )
    fact( n ).size
  rescue
    $!
  end   
end
 
t = TCOTest.new
 
# normal method
puts t.fact_size( 10000 )  # => stack level too deep
 
# enable tail-call optimization
class TCOTest
  tailcall_optimize :fact
end
 
# tail-call optimized method
puts t.fact_size( 10000 )  # => 14808

Esta solución consiste en jugar con catch’s,throw’s y Thread.current para relanzar el mismo método una y otra vez sin tener que crear un nuevo frame en el Stack, ya que el codigo del metodo se encuentra definido en un bloque y por tanto reutiliza el codigo.

La segunda opción:

def fib(i, n = 1, result = 0)
  if i == -1
    result
  else
    i, n, result = i - 1, n + result, n
    redo
  end
end
 
fib(10000)

Esta solución consiste en hacer uso de la palabra redo la cual reinicia la ejecución de cualquier loop o iterador. El problema con redo es que, como acabo de decir, solo se puede utilizar en loops o iteradores y el método fib anterior no es ninguno de ellos. Por lo que el autor de la página de que se extrajeron las soluciones dice:

Unfortunately, “The redo statement restarts the current iteration of a loop or iterator”, so it only throws a LocalJumpError

Gracias señor espartano.

Así es, esto es Ruby y siempre hay un workaround para todo. En este caso, consiste en crear un nuevo método cuyo cuerpo este contenido en un bloque.

define_method(:acc) do |i, n, result|
  if i == -1
    result
  else
    i, n, result = i - 1, n + result, n
    redo
  end
end
 
def fib(i)
  acc(i, 1, 0)
end
 
fib(10000)  # Yeah!

Y ya podemos utilizar redo. Fin!!

Para mas información, hay un thread en esta lista de correo en el que debaten sobre este tema: Ruby tail recursion.

• Paso 1 : Abrir en un editor el fichero handler.rb perteneciente a la gema starling-starling.
• Paso 2 : En el método Handler#set_data añadir la siguiente linea justo antes de hacer el pack para generar la variable internal_data.

  ...
  expiry = Time.now.to_i + expiry.to_i unless expiry.to_i == 0
  ...

• Paso 3 : Guarda y re-arranca el starling.Todo debería de ir como la seda.

Con esto, lo único que hemos hecho es corregir un pequeño bug que hay en Handler#get ya que en este método solo se devuelve un mensaje si su expiry es 0 o si expiry es mayor que now (now en este contexto es Time.now.to_i ). El fallo viene de comparar a now (valor unix time) con expiry el cual es solo un offset desde el momento en el que decidimos guardar un mensaje en starling.

  ...
  break if expiry == 0 || expiry >= now
 
  @expiry_stats[key] += 1
  expiry, data = nil
  ...

Con la linea que añadimos al método Handler#set_data forzamos que la comparación sea entre dos valores unix time.Uno refiriéndose al momento actual (now) y otro al momento en el que expirara el mensaje (la suma de Time.now.to_i en el momento del almacenarlo y el tiempo de vida del mensaje).

Actualmente estoy trabajando en un proyecto donde es necesario que dos aplicaciones realizadas en Rails se comuniquen entre si mediante mediante Rest.Para conseguir esto, una de las aplicaciones incluye un plugin (proxy) en la otra.En este plugin se encarga de lo siguiente:

• Se definen los datos necesarios para esta comunicacion entre aplicaciones como así requiere ActiveResource::Base
• Se registra un observador que observara (valga la redundancia) uno de los modelos en la aplicación receptora el plugin

Antes de continuar con este post, tengo que confesar una cosilla, observar un modelo desde un plugin es un problema, si y solo si se hace en modo desarrollo.¿Y por qué?

Si no te interesa saber el porque de los problemas y has llegado hasta aqui buscando una solucion, con indicar a Rails que recargue los plugins en cada petición tendrás el asunto resuelto.

Para ello sigue los siguientes pasos:

1º. Indicar a Rails que quieres recargar los plugins

En config/environment.rb añade esta linea:

config.reload_plugins = true

Con esto lo único que hacemos en realidad, es evitar que el path /lib de cada plugin sea incluido en Dependencies.load_once_paths

Pero esto puede que no nos arregle nuestro problema y para muestra un ejemplo:

Arrancare el webrick en modo debug con un breakpoint en el método dispatch del fichero dispatcher.rb, método invocado para cada petición.

def dispatch(cgi = nil, session_options = CgiRequest::DEFAULT_SESSION_OPTIONS, output = $stdout)
    debugger
    new(output).dispatch_cgi(cgi, session_options)
end

Arrancamos y enviamos una peticion:

=> Booting WEBrick...
=> Debugger enabled
=> Rails 2.1.1 application started on http://events.trabenet.local:3001
=> Ctrl-C to shutdown server; call with --help for options
[2008-11-16 21:37:24] INFO  WEBrick 1.3.1
[2008-11-16 21:37:24] INFO  ruby 1.8.7 (2008-08-08) [i686-darwin8]
[2008-11-16 21:37:25] INFO  WEBrick::HTTPServer#start: pid=1394 port=3001
/opt/local/lib/ruby/gems/1.8/gems/actionpack-2.1.1/lib/action_controller/dispatcher.rb:36
new(output).dispatch_cgi(cgi, session_options)
(rdb:2)

El plugin del que tratamos declara una constante, EventObserver. Veamos si existe:

(rdb:2) EventObserver
EventObserver
(rdb:2) EventObserver.object_id
25840630

Perfecto.

Como en mi config/environment.rb indico que quiere recargar mis plugins, tenemos que:

(rdb:2) Dependencies.load_once_paths
[]

Y los load_paths son:

(rdb:2) pp Dependencies.load_paths
["/Users/madtrick/programacion/trabesoluciones/trabenet-sources/trabenet-events/app/controllers/",
 "/Users/madtrick/programacion/trabesoluciones/trabenet-sources/trabenet-events/app",
 "/Users/madtrick/programacion/trabesoluciones/trabenet-sources/trabenet-events/app/models",
 "/Users/madtrick/programacion/trabesoluciones/trabenet-sources/trabenet-events/app/controllers",
 "/Users/madtrick/programacion/trabesoluciones/trabenet-sources/trabenet-events/app/helpers",
 "/Users/madtrick/programacion/trabesoluciones/trabenet-sources/trabenet-events/config",
 "/Users/madtrick/programacion/trabesoluciones/trabenet-sources/trabenet-events/vendor",
 "/opt/local/lib/ruby/gems/1.8/gems/rails-2.1.1/lib/../builtin/rails_info/",
 "/Users/madtrick/programacion/trabesoluciones/trabenet-sources/trabenet-events/vendor/plugins/background/lib",
 "/Users/madtrick/programacion/trabesoluciones/trabenet-sources/trabenet-events/vendor/plugins/localization-with-gettext/lib",
 "/Users/madtrick/programacion/trabesoluciones/trabenet-sources/trabenet-events/vendor/plugins/localized_url_helpers/lib",
 "/opt/local/lib/ruby/gems/1.8/gems/mbleigh-acts-as-taggable-on-1.0.2/lib",
 "/Users/madtrick/programacion/trabesoluciones/trabenet-sources/trabenet-events/vendor/plugins/thinking-sphinx/lib",
 "/Users/madtrick/programacion/trabesoluciones/trabenet-sources/trabenet-events/vendor/plugins/trabenet-auth/lib",
 "/Users/madtrick/programacion/trabesoluciones/trabenet-sources/trabenet-events/vendor/plugins/trabenet-core/lib",
 "/Users/madtrick/programacion/trabesoluciones/trabenet-sources/trabenet-events/vendor/plugins/trabenet-people-proxy/lib",
 "/Users/madtrick/programacion/trabesoluciones/trabenet-sources/trabenet-events/vendor/plugins/trabenet_subscriptions_proxy/lib",
 "/opt/local/lib/ruby/gems/1.8/gems/will_paginate-2.2.2/lib"]

Por tanto en cada nueva petición los plugins serán candidatos a ser recargados.

Veamos si esto es así con otra petición:

127.0.0.1 - - [16/Nov/2008:22:00:21 CET] "POST /events.xml HTTP/1.1" 201 1
- -> /events.xml
/opt/local/lib/ruby/gems/1.8/gems/actionpack-2.1.1/lib/action_controller/dispatcher.rb:36
new(output).dispatch_cgi(cgi, session_options)
(rdb:11) EventObserver.object_id
25840630

Pues no, aquí no se recarga nada!! porque como podemos apreciar , el object_id de la constante es el mismo que el de la primera petición, es decir son el mismo objeto.

2º.Segundo paso de la solución,descargar las constantes del entorno

La explicación a que el objeto representado por EventObserver sea el mismo esto es la siguiente:

Para empezar hay que tener en cuanta que para que una constante definida en un plugin tenga validez en Rails es necesario que ocurra una de las siguientes posibilidades:

• Cuando se inicializa el entorno de Rails, para cada plugin se evalúa su fichero init.rb de forma que podemos utilizar llamadas a require para incluir el código contenido en el directorio /lib del plugin (y por tanto las constantes de este), en Rails.
• Que las constantes sean cargadas de forma dinámica como ya explique en este post, de forma que cada una de estas constantes incluidas de esta forma pasa a formar parte del array Dependencies.autoloaded_constants.Esto ultimo es importante.

La importancia de la forma en la que se carga una constante en Rails, reside en que es lo que se recarga en cada petición y que es lo que se descarga tras cada peticion.Tras cada petición (si estamos en modo de desarrollo) se enviara un mensaje a Dependencies.clear.

def clear
      log_call
      loaded.clear
      remove_unloadable_constants!
end

La parte interesante de Dependencies.clear es la llamada al método remove_unloadable_constants!

def remove_unloadable_constants!
      autoloaded_constants.each { |const| remove_constant const }
      autoloaded_constants.clear
      explicitly_unloadable_constants.each { |const| remove_constant const }
end

En este método se borra la constante indicada del modulo o clase correspondiente. Como se puede apreciar se borraran tanto las constante “autocargadas” como las indicadas explicitaménte en Dependencies.explicitly_unloadable_constants.

A pesar de haber indicado en nuestro environment.rb que queríamos recargar los plugins (config.reload_plugins=true); para cada petición no se volverá a evaluar el fichero init.rb de cada plugin y por tanto, si nuestras constantes se cargan en Rails mediante llamadas a require (no existirán en el array Dependencies.autoloaded_constants) ; estas no volverán a ser cargadas debido a que no habrá necesidad de ello al no haber sido descargadas en Dependencies.explicitly_unloadable_constants.Para solucionar esto podemos optar por una de estas opciones:

• No utilizar requires y dejar la carga de las constantes en manos de los mecanismos de Rails
• Hacer uso de Depedencies.explicitly_unloadable_constants, indicando en dicho array las constantes que queremos que se descarguen tras cada petición

Volviendo a nuestro ejemplo, probemos una de estas opciones.Utilizaremos Depedencies.explicitly_unloadable_constants.

En mi caso, defino las constantes que quiero que se descargen en el init.rb del plugin (por eso de tener todo juntito : ) ).

Dependencies.explicitly_unloadable_constants = 'EventObserver'

Y lo probamos de nuevo con webrick:

=> Booting WEBrick...
=> Debugger enabled
=> Rails 2.1.1 application started on http://events.trabenet.local:3001
=> Ctrl-C to shutdown server; call with --help for options
[2008-11-17 00:01:15] INFO  WEBrick 1.3.1
[2008-11-17 00:01:15] INFO  ruby 1.8.7 (2008-08-08) [i686-darwin8]
[2008-11-17 00:01:15] INFO  WEBrick::HTTPServer#start: pid=1442 port=3001
/opt/local/lib/ruby/gems/1.8/gems/actionpack-2.1.1/lib/action_controller/dispatcher.rb:36
new(output).dispatch_cgi(cgi, session_options)
(rdb:2) EventObserver.object_id
25840560

Lanzamos otra petición.

127.0.0.1 - - [17/Nov/2008:00:01:17 CET] "POST /events.xml HTTP/1.1" 201 1
- -> /events.xml
/opt/local/lib/ruby/gems/1.8/gems/actionpack-2.1.1/lib/action_controller/dispatcher.rb:36
new(output).dispatch_cgi(cgi, session_options)
(rdb:11) EventObserver.object_id
27418300

Como se puede apreciar en esta ocasión son objetos distintos y por tanto realmente se recargado la constante.

Tras hacer esto, ya podemos observar con tranquilidad a nuestros modelos desde el plugin.

A partir de aquí voy a explicar el porque de la necesidad de recargar el contenido de nuestros plugins para poder observar a un modelo en modo de desarrollo.

Como explique antes, si no se recarga el contenido de nuestros plugins y en concreto la clase donde definimos el observador del modelo, tendremos un problema.¿Y por qué?

Primero , algunas cosillas a tener en consideración:

• Los Observadores en Rails utilizan el patrón Singleton
• Donde se instancian los observadores

Empezaremos por el segundo punto.

En Rails, existen dos puntos prefijados donde se instancian los observadores correspondientes a cada modelo.El primero es en el fichero initializer.rb en el metodo de clase process donde se invoca el metodo load_observers

def process
...
load_observers
end

Con load_observers como sigue,

def load_observers
      if gems_dependencies_loaded && configuration.frameworks.include?(:active_record)
        ActiveRecord::Base.instantiate_observers
      end
end

En ActiveRecord::Base.instantiate_observers crearemos para cada modelo sus observadores y será aquí donde comienzen nuestros quebraderos de cabeza.

def instantiate_observers
        return if @observers.blank?
        @observers.each do |observer|
          if observer.respond_to?(:to_sym) # Symbol or String
            temp = observer.to_s.camelize.constantize
            temp.instance
          elsif observer.respond_to?(:instance)
            observer.instance
          else
            raise ArgumentError, "#{observer} must be a lowercase, underscored class name (or an instance of the class itself) responding to the instance method. Example: Person.observers = :big_brother # calls BigBrother.instance"
          end
        end
end

POR TERMINAR, lo hare en otro post : )

Esta funcionalidad junto con la posibilidad de saber cuando un modulo ha sido incluido en una clase nos permite añadir funcionalidad a las clases que incluyen el modulo sin que estan tengan que percibirlo.

Un ejemplo:

class Module
  def included(base)
    p "Included module " + name
 
    without = "test_method_#{name}_without_filters".to_sym
    with ="test_method_#{name}_with_filters".to_sym
    base.class_eval do
      alias_method without, :test_method
      alias_method :test_method, with
    end
 
  end
end

Lo que he hecho es redefinir el metodo included para que todos los modulos indiquen que ha sido incluidos y que hagan un alias sobre el metodo “test_method“.

Hay que tener en cuenta que alias_method no sobreescribe el metodo original, sino que hace una guarda una referencia a este, de forma que aun pueda ser invocado.

module A
 
  def test_method_A_with_filters
    p "Doing something really important in module A"
    test_method_A_without_filters
  end
 
end
 
module B
 
  def test_method_B_with_filters
    p "Doing something really important in module B"
    test_method_B_without_filters
  end
 
end
 
 
class Test
 
  def test_method
      p "Inside method of class A"
 
      p "Backtrace:"
      caller.each do |text| p text end
      return
  end
 
  include A
  include B
end

Creamos los modulos, la clase e incluimos los primeros en dicha clase.Hasta aqui nada nuevo bajo el sol.

Probemos entonces el codigo en irb,

madtrick:~/programacion/ruby madtrick$ irb
irb(main):001:0> require "test30"
"Included module A"
"Included module B"
=> true
 
irb(main):002:0> Test.new.test_method
"Doing something really important in module B"
"Doing something really important in module A"
"Inside method of class A"
 
"Backtrace:"
"./test30.rb:14:in `test_method_B_without_filters'"
"./test30.rb:32:in `test_method'"
"(irb):2:in `irb_binding'"
"/opt/local/lib/ruby/1.8/irb/workspace.rb:52:in `irb_binding'"
":0"
=> nil

Si hechamos un vistazo a la salida generada en irb,

irb(main):001:0> require "test30"
"Included module A"
"Included module B"
=> true

Los modulos se incluyen en la clase en el orden deseado

irb(main):002:0> Test.new.test_method
"Doing something really important in module B"
"Doing something really important in module A"
"Inside method of class A"

Ahora creamos un objeto de tipo Test e invocamos sobre él el metodo “test_method”…!Pero que ha pasado aqui¡!De donde salen esa lineas¡No no pongamos nerviosos y averigüemos que pasa.

Cuando redefinimos el metodo included de la clase module, realizamos unos alias.
Para el modulo A:

• Nuevo nombre : test_method_A_without_filters,nombre antiguo: test_method
• Nuevo nombre : test_method, nombre_antiguo test_method_A_with_filters

Para el modulo B , lo mismo pero cambiando la A por una B.

El resultado de estos alias es el que vemos en la salida de irb, al invocar sobre un objeto de la clase Test
su metodo de instancia “test_method” lo primero que vemos no es “Inside method of class A” sino “Doing something really important in module B“,seguido de un “Doing something really important in module A” para finalmente ver nuestro esperado “Inside method of class A“,esto es asi porque:

1. El ultimo modulo incluido fue el B, por tanto su alias “sobreescribioo” al creado por el modulo A.Es decir al hacer Test.new.test_method en realidad estamos invocando a test_method_B_with_filters
2. Tras ejecutar este metodo, invocamos al metodo “original”, que en este caso no es el definido en la clase, sino el alias realizado por el modulo A
3. Tras ejecutar este ultimo alias, volvemos a invocar al metodo original (alias de “test_method_A_without_filters”) quien finalmente si que es el metodo de la clase Test

Utilizando caller podemos saber la stacktrace de nuestro programa y asi saber cual fue la direccion de los mensajes.Esto lo podemos ver en este trozo de la salida de irb,

"Backtrace:"
"./test30.rb:19:in `test_method_B_without_filters'"
"./test30.rb:30:in `test_method'"
"(irb):2:in `irb_binding'"
"/opt/local/lib/ruby/1.8/irb/workspace.rb:52:in `irb_binding'"
":0"

Teniendo en cuenta que las primeras lineas indican los ultimos mensajes.Tenemos que:

En la linea 30 vamos enviar un mensaje tras recibir uno con destino a “test_method” alias de “test_method_B_with_filters“,

28
29
30
31

  def test_method_B_with_filters
    p "Doing something really important in module B"
    test_method_B_without_filters
  end

En la linea 19 vamos a enviar un mensaje tras recibir uno con destino “test_method_B_without_filters”
el cual es un alias de “test_method“,

17
18
19
20

 def test_method_A_with_filters
    p "Doing something really important in module A"
    test_method_A_without_filters
  end

Como se puede apreciar es una forma bastante sencilla de añadir funcionalidad sin influir para nada en las clases.Y de aqui es de donde saque el titulo, porque literalmente estamos encadenando metodos.

Para terminar
Si alguien le extraña la coletilla _filters que utilize para hacer los alias , tiene su explicacion.Ultimamente estoy curioseando en el codigo de Rails, y para poder seguir un orden me voy guiando por el orden el que se procesan las peticiones ,gracias al debugger para webrick y otros servidores.Bueno la cosa es que llegue al fichero filters.rb donde me encontre con este codigo,

 module InstanceMethods # :nodoc:
      def self.included(base)
        base.class_eval do
          alias_method_chain :perform_action, :filters
          alias_method_chain :process, :filters
        end
      end
...

¿alias_method_chain?, no me sonaba para nada, asi que tras una consulta a google llegue a esto:

All over the internals of Rails you’ll find code like this in a module:

module Layout #:nodoc:
def self.included(base)
base.extend(ClassMethods)
base.class_eval do
alias_method :render_with_no_layout, :render
alias_method :render, :render_with_a_layout
# … etc
This makes it so that when the module is included into the base class, it adds behavior onto some method in that class without the method having to be aware of the fact that it’s being enhanced

En resumidas cuentas, que alias_method_chain hace lo que acabos de hacer nosotros pero un poquillo mejor ya que se puede aplicar a cualquier metodo, no solo a test_method como en nuestro caso.

Volviendo a lo de la coletilla _filters, la explicacion es que donde vi el primer ejemplo de alias_method_chain fue en el codigo indicado arriba y entonces fue lo primero que se me ocurrio.

La primera idea que me paso por la cabeza y que probe fue:

class Test
 
private
def Test.class_method
p "inside private class method"
end
 
end

Si pruebo este codigo en irb,

madtrick:~/programacion/ruby madtrick$ irb
irb(main):001:0> require "test28"
> true
irb(main):002:0> Test.class_method
"inside private class method"
> nil

Podemos ver que no, que esto no funciona porque me deja llamar al metodo perfectamente y todos sabemos que eso no puede pasar ya que en ruby los metodos privados solo permiten ser invocados con un “self” explicito.Realmente lo que acabo de decir no es del todo cierto, ya que los utilizando el metodo send para enviar el mensaje da igual la visibilidad del metodo que lo reciva.

Lo que no entiendo es porque falla, supongo que sera porque la restriccion de visibilidad que implica private solo afectara a los metodos de instancia de la clase.Si alguien quiere aportar mas luz sobre esto…

Volviendo al tema, probemos con el metodo private_class_method.Este metodo cambia la visibilidad de cualquier metodo a privada.Veamos un ejemplo:

class Test
 
def Test.class_method
p "inside private class method"
end
 
private_class_method :class_method
end

Lo probamos,

madtrick:~/programacion/ruby madtrick$ irb
irb(main):001:0> require "test28"
> true
irb(main):002:0> Test.class_method
NoMethodError: private method `class_method' called for Test:Class
from (irb):2

Esto ya es otra cosa,es lo esperado.Este metodo esta muy bien ya que permite cambiar la visibilidad a que por ejemplo herede nuestra clase.

Pero aun nos queda una manera mas de definidir metodos de clase que sean privados.

Como en ruby todo es un objeto, las señoras clases tambien son objetos (de la clase Class).Por tanto tambien pueden tener metodos de instancia, que a efectos practicos se comportan como los metodos de clase definidos de forma normal y corriente en una clase.

¿Y como añado yo metodos de instancia a una clase?Pues hay varios metodos pero el mas sencillo (o por lo menos eso me parece a mi -se aceptan sugerencias) es el siguiente:

class Test
    class << self
      private
        def class_method
         p "inside private class method"
        end
    end
end

Lo que acabamos de hacer es abrir la metaclase o clase-virtual de la clase para añadir un el metodo class_method con visibilidad privada.Para el que no sepa que son las clases virtuales o metaclases, le recomiendo leer los enlaces que menciono al final del post.

Si ejecutamos esto en irb,

madtrick:~/programacion/ruby madtrick$ irb
irb(main):001:0> require "test28"
> true
irb(main):002:0> Test.class_method
NoMethodError: private method `class_method' called for Test:Class
from (irb):2

Una vez mas, funciona correctamente.

Si quieres saber algo mas sobre las metaclasses o clases-virtuales te recomiendo que le heches un vistazo a:

Seein metaclasses clearly

Why virtual classes?