’ Vamos a juntar lo que sabemos sobre las variables de instancia, self y las clases singleton. Anteriormente hemos dicho que con métodos accesores a nivel de clase vamos a obtener y establecer el valor de una variable de instancia definida en un objeto de clase. Sin embargo, Ruby ya tiene a attr_accessor, que define los métodos getter y setter (obtenedor y establecedor). Normalmente, sin embargo, estos se definen como métodos de instancia y por lo tanto tendrán acceso a los valores almacenados en las instancias de una clase. Para que funcionen con las variables de instancia a nivel de clase, tenemos que invocar a attr_accessor en la clase singleton: class Test @var = 99

333

class << self attr_accessor :var end end puts “Original value = #{Test.var}” Test.var = “cat” puts “New value = #{Test.var}” produce: Original value = 99 New value = cat

Herencia y Visibilidad Hay una arruga oscura cuando se trata la definición de método y la herencia de clase. Dentro de una definición de clase, puede cambiar la visibilidad de un método en una clase antecesora.

Por ejemplo, se puede hacer algo como esto:

class Base def a_method puts “Got here” end private :a_method end class Derived1 < Base public :a_method end class Derived2 < Base end En este ejemplo, usted sería capaz de invocar un_metodo en instancias de la clase Derived1, pero en cambio, no en instancias de Base o Derived2. Por tanto, ¿cómo logra Ruby esta hazaña de tener un método con dos visibilidades diferentes? En pocas palabras, se engaña. Si una subclase cambia la visibilidad de un método en uno de los antecesores, Ruby efectivamente inserta un método proxy oculto en la subclase que invoca al método original utilizando super. A continuación, establece la visibilidad de ese proxy para lo que se solicitó. Esto significa que el siguiente código: class Derived1 < Base public :a_method end

es efectivamente el mismo que este:

class Derived1 < Base def a_method(*) super end public :a_method end La llamada a super puede acceder a métodos de los padres independientemente de su visibilidad, por lo que la reescritura permite a la subclase reemplazar las reglas de visibilidad su antecesor. Atemoriza, ¿eh?

334

Módulos y Mixins Sabemos que cuando se incluye un módulo en una clase Ruby, los métodos de instancia de ese módulo están disponibles como métodos de instancia de la clase. module Logger def log(msg) STDERR.puts Time.now.strftime(“%H:%M:%S: ”) + “#{self} (#{msg})” end end class Song include Logger end class Album include Logger end s = Song.new s.log(“created”) produce: 11:53:26: # (created) La implementación Ruby de include es muy simple: el módulo que se incluye es efectivamente añadido como una superclase de la clase que se define. Es como si el módulo fuera el padre de la clase en la que se mezcla. Y eso sería el final de la descripción a excepción de una pequeña pega. Debido a que el módulo es inyectado en la cadena de superclases, se debe mantener un vínculo con la clase padre original. Si no, no habría manera de atravesar la cadena de superclases para buscar métodos. Sin embargo, usted puede mezclar el mismo módulo en diferentes clases, y estas clases podrían tener cadenas de superclase totalmente diferentes. Si hubiera sólo un objeto módulo mezclado en todas estas clases, no habría manera de hacer el seguimiento de las diferentes superclases para cada una. Para evitar esto, Ruby utiliza un truco ingenioso. Cuando se incluye un módulo en la clase Ejemplo, Ruby crea un nuevo objeto de clase, haciéndole la superclase de Ejemplo, y luego establece la superclase de la nueva clase a la superclase original de Ejemplo. A continuación, referencia al módulo desde este nuevo objeto de clase de tal manera que cuando se busca un método en esta clase, en realidad se busca en el módulo, como se muestra en la figura en la página siguiente. Un bonito efecto secundario de este arreglo es que si usted cambia un módulo después de su inclusión en una clase, los cambios se reflejan en la clase (y en los objetos de la clase). De esta manera, los módulos se comportan igual que las clases. module Mod def greeting “Hello” end end class Example include Mod end ex = Example.new puts “Before change, greeting is #{ex.greeting}” module Mod def greeting “Hi”

335

end end puts “After change, greeting is #{ex.greeting}” produce: Before change, greeting is Hello After change, greeting is Hi

Si un mismo módulo incluye otros módulos, una cadena de clases proxy se añadiran a cualquier clase que incluya a este módulo, un proxy para cada módulo que esté directa o indirectamente incluidos. Por último, Ruby incluirá un módulo sólo una vez en una cadena de herencia --incluir un módulo que ya está incluido en una de sus superclases no tiene ningún efecto.

extend El método include añade efectivamente un módulo como una superclase de self. Se utiliza dentro de una definición de clase para que los métodos de instancia en el módulo estén disponibles para las instancias de la clase. Sin embargo, a veces es conveniente añadir los métodos de instancia a un objeto particular. Esto se hace con Object#extend. He aquí un ejemplo: module Humor def tickle “#{self} says hee, hee!” end

336

end obj = “Grouchy” obj.extend Humor puts obj.tickle produce: Grouchy says hee, hee!

Vamos a parar un segundo para pensar cómo puede implementarse esto.

Cuando Ruby ejecuta obj.tickle en este ejemplo de código, se hace el truco habitual de buscar en la clase de obj un método llamado tickle (cosquillas). Para que extend funcione, tiene que añadir los métodos de instancia del módulo Humor en la cadena de superclases para la clase de obj. Por lo tanto, al igual que con las definiciones de métodos singleton, Ruby crea una clase singleton para obj y luego incluye el módulo Humor en esa clase. De hecho, sólo para demostrar que esto es todo lo que sucede, aquí está la implementación en C de extend en el actual intérprete de Ruby 1.9: void rb_extend_object(VALUE obj, VALUE module) { rb_include_module(rb_singleton_class(obj), module); } Hay un truco interesante con extend. Si lo usa en una definición de clase, los métodos de módulo se convierten en métodos de clase. Esto se debe a que la llamada a extend es equivalente a self.extend, por lo que los métodos se añaden a self, que en una definición de clase es la clase misma.

He aquí un ejemplo de cómo agregar métodos de módulo a nivel de clase:

module Humor def tickle “#{self} says hee, hee!” end end class Grouchy extend Humor end puts Grouchy.tickle produce: Grouchy says hee, hee! Más adelante, vamos a ver cómo utilizar extend para añadir métodos de estilo macro a una clase.

Metaprogramación de Macros a Nivel de Clase Si se ha utilizado Ruby para cualquier toma de tiempo, hay muchas posibilidades de haber utilizado attr_accessor, el método que define los métodos para leer y escribir las variables de instancia: class Song attr_accessor :duration end

Si se ha escrito una aplicación en Ruby on Rails, probablemente se ha utilizado has_many:

class Album < ActiveRecord::Base has_many :tracks end

337

Ambos son ejemplos de métodos a nivel de clase que generan código entre bastidores. Debido a la forma en que se expanden en algo más grande, la gente a veces les llama métodos macro. Vamos a crear un ejemplo trivial y luego construirlo en algo realista. Vamos a empezar por la implementación de un simple método que añade capacidades de registro a instancias de una clase. Anteriormente lo hicimos con un módulo --esta vez lo haremos utilizando un método a nivel de clase. Esta es la primera iteración: class Example def self.add_logging def log(msg) STDERR.puts Time.now.strftime(“%H:%M:%S: ”) + “#{self} (#{msg})” end end add_logging end ex = Example.new ex.log(“hello”) produce: 11:53:26: # (hello) Claramente esta es una pieza tonta de código. Tengan paciencia conmigo --voy a mejorar. Pero aún podemos aprender algunas cosas de él. En primer lugar, la notificación add_logging es un método de clase --se define en la clase singleton del objeto clase. Eso significa que podemos llamarlo más tarde en la definición de clase sin un receptor explícito, porque self se establece en el objeto clase dentro de una definición de clase. Luego hay que observar que este método add_logging contiene una definición de método anidada. Esta definición interna se vá a ejecutar sólo cuando se llama al método add_logging. El resultado es que log es definido como un método de instancia de la clase Example. Vamos a dar un paso más. Podemos definir el método add_logging en una clase y luego usarlo en una subclase. Esto funciona porque la jerarquía de la clase singleton es paralela a la jerarquía de clases regular. Como resultado, los métodos de clase en una clase padre están disponibles en la clase hija, tal como muestra el siguiente ejemplo. class Logger def self.add_logging def log(msg) STDERR.puts Time.now.strftime(“%H:%M:%S: ”) + “#{self} (#{msg})” end end end class Example < Logger add_logging end ex = Example.new ex.log(“hello”) produce: 11:53:26: # (hello) Piense de nuevo en los dos ejemplos al inicio de esta sección. Ambos funcionan de esta manera. attr_accessor es un método de clase definido en la clase Module y así está disponible en todas las definiciones de módulo y clase. has_many es un método de clase definido en la clase Base dentro

338

del módulo ActiveRecord de Rails y por lo tanto disponible para todas las clases de esa subclase ActiveRecord::Base. Este ejemplo, todavía no es muy convincente. Sería más fácil aún añadir directamente el método log como un método de instancia de nuestra clase Logger. Pero, ¿qué pasa si queremos construir una versión diferente del método log para cada clase que se utiliza? Por ejemplo, vamos a agregar la posibilidad de añadir una breve clase específica de identificación de cadena al inicio de cada mensaje de registro. Queremos ser capaces de decir algo como esto: class Song < Logger add_logging “Song” end class Album < Logger add_logging “CD” end Para ello, vamos a definir el método log sobre la marcha. Ya no podemos utilizar una sencilla definición estilo def...end. En su lugar, usaremos define_method, uno de los pilares de la metaprogramación. define_method toma el nombre de un método y un bloque, definiendo un método con el nombre dado y con el bloque como el cuerpo del método. Cualquier argumento en la definición del bloque se convierte en parámetro para el método que se está definiendo. class Logger def self.add_logging(id_string) define_method(:log) do |msg| now = Time.now.strftime(“%H:%M:%S”) STDERR.puts “#{now}-#{id_string}: #{self} (#{msg})” end end end class Song < Logger add_logging “Tune” end class Album < Logger add_logging “CD” end song = Song.new song.log(“rock on”) produce: 11:53:26-Tune: # (rock on)

Hay una sutileza importante en este código. El cuerpo del método log contiene la siguiente línea:

STDERR.puts “#{now}-#{id_string}: #{self} (#{msg})” El valor now es una variable local, y msg es el parámetro para el bloque. Pero id_string es el parámetro para el método add_logging que lo contiene. Es accesible en el interior del bloque debido a que las definiciones de bloque crean cierres, permitiendo que el contexto en el que se define el bloque sea trasladado y utilizado cuando se utiliza el bloque. En este caso, estamos dando un valor a partir de un método a nivel de clase y utilizándolo en un método de instancia que estamos definiendo. Este es un patrón común para crear este tipo de macros de nivel de clase. Así como se pasan parámetros desde un método de clase al cuerpo de un método que se define, también se puede utilizar el parámetro para determinar el nombre del método o métodos a crear. He aquí un

339

ejemplo que crea un nuevo tipo de attr_accessor que registra todas las asignaciones a una variable de instancia dada: class AttrLogger def self.attr_logger(name) attr_reader name define_method(“#{name}=”) do |val| puts “Assigning #{val.inspect} to #{name}” instance_variable_set(“@#{name}”, val) end end end class Example < AttrLogger attr_logger :value end ex = Example.new ex.value = 123 puts “Value is #{ex.value}” ex.value = “cat” puts “Value is now #{ex.value}” produce: Assigning 123 to value Value is 123 Assigning “cat” to value Value is now cat Una vez más, se utiliza el hecho de que el bloque que define el cuerpo del método es un cierre, accediendo al nombre del atributo en la cadena de mensaje de registro. Hay que notar que también se hace uso del hecho de que attr_reader es simplemente un método de clase --que se puede llamar dentro de nuestro método de clase para definir el método de lectura de nuestros atributos. Hay que tener en cuenta otro detalle común de metaprogramación --usamos instance_variable_set para establecer el valor de una variable de instancia (duh). Hay un correspondiente método _get que obtiene el valor de una variable de instancia por su nombre.

Macros y Módulos de Clase A veces, es perfectamente aceptable definir macros de clase en una clase y luego utilizar estos métodos macro en las subclases de esa clase. Otras veces sin embargo, no es apropiado utilizarlos en subclases, bien porque ya tenemos la subclase de alguna otra clase o bien porque nuestro estético diseño se rebela contra algo así como una canción de una subclase de un registrador. En estos casos, se puede utilizar un módulo que contenga la implementación de metaprogramación. Como hemos visto, utilizando extend dentro de una definición de clase se añaden métodos en un módulo como métodos de clase para la clase que se define: module AttrLogger def attr_logger(name) attr_reader name define_method(“#{name}=”) do |val| puts “Assigning #{val.inspect} to #{name}” instance_variable_set(“@#{name}”, val) end end end class Example

340

extend AttrLogger attr_logger :value end ex = Example.new ex.value = 123 puts “Value is #{ex.value}” ex.value = “cat” puts “Value is now #{ex.value}” produce: Assigning 123 to value Value is 123 Assigning “cat” to value Value is now cat Las cosas se ponen un poco más complicadas si se quieren añadir tanto los métodos de clase como los métodos de instancia en la clase que se define. Aquí hay una técnica, muy utilizada en la implementación del marco de trabajo de Rails. Se hace uso de un método gancho de Ruby, included, el cual es llamado automáticamente por Ruby cuando se incluye un módulo en una clase. Se le pasa el objeto clase de la clase que se define. module GeneralLogger # Método de instancia que se añade a cualquier clase que lo incluya def log(msg) puts Time.now.strftime(“%H:%M: ”) + msg end # módulo que contiene los métodos de clase que se añadirán module ClassMethods def attr_logger(name) attr_reader name define_method(“#{name}=”) do |val| log “Assigning #{val.inspect} to #{name}” instance_variable_set(“@#{name}”, val) end end end # extender la clase afitriona con los métodos de clase cuando se incluyen def self.included(host_class) host_class.extend(ClassMethods) end end class Example include GeneralLogger attr_logger :value end ex = Example.new ex.log(“New example created”) ex.value = 123 puts “Value is #{ex.value}” ex.value = “cat” puts “Value is #{ex.value}” produce:

341

11:53: New example created 11:53: Assigning 123 to value Value is 123 11:53: Assigning “cat” to value Value is cat Observar cómo la devolución de llamada incluida se utiliza para extender la clase anfitriona con los métodos definidos en el módulo ClassMethods interior. Ahora, como un ejercicio, tendrá que ejecutar el ejemplo anterior de su cabeza. Para cada línea de código, calcular el valor de self. Dominando esto se domina prácticamente este tipo de metaprogramación en Ruby.

Otras Dos Formas de Definición de Clases En el caso de que pensaramos que habíamos agotado las formas de definir las clases en Ruby, vamos a echar un vistazo a otras dos opciones.

Expresiones de Subclases La primera forma no es realmente nada nuevo --no es más que una generalización de la sintaxis de definición de clase regular. Sabemos que podemos escribir lo siguiente: class Parent ... end class Child < Parent ... end Lo que quizás no sabíamos es que la cosa a la derecha de < no tiene por qué ser sólo un nombre de clase, sino que puede ser cualquier expresión que devuelva un objeto de clase. En este ejemplo de código, tenemos la constante Parent. Una constante es una simple forma de expresión, y en este caso la constante Parent contiene el objeto clase de la primera clase que hemos definido. Ruby cuenta con una clase llamada Struct, que permite definir clases que contienen sólo atributos de datos. Por ejemplo, podríamos escribir lo siguiente: Person = Struct.new(:name, :address, :likes) dave = Person.new(‘Dave’, ‘TX’) dave.likes = “Programming Languages” puts dave produce: # El valor de retorno de Struct.new(...) es un objeto de clase. Al asignarlo a la constante Person, se puede utilizar Person a partir de entonces como si se tratara de cualquier otra clase. Pero queremos cambiar el método to_s de nuestra estructura. Podríamos hacerlo abriendo la clase y escribiendo el siguiente método: Person = Struct.new(:name, :address, :likes) class Person def to_s “#{self.name} lives in #{self.address} and likes #{self.likes}” end end 342

Sin embargo, podemos hacerlo más elegante (aunque a costa de un objeto de clase adicional) escribiendo lo siguiente: class Person < Struct.new(:name, :address, :likes) def to_s “#{self.name} lives in #{self.address} and likes #{self.likes}” end end dave = Person.new(‘Dave’, ‘Texas’) dave.likes = “Programming Languages” puts dave produce: Dave lives in Texas and likes Programming Languages

Creación de Clases Singleton

Vamos a ver algo de código Ruby:

class Example end ex = Example.new Cuando llamamos a Example.new, estamos invocando el método new en el objeto clase Example. Esto es sólo una llamada regular a método --Ruby busca el método new en la clase del objeto (la clase de Example es Class) y lo invoca. Resulta que también podemos invocar Class#new directamente: some_class = Class.new puts some_class.class produce: Class

Si se le pasa a Class.new un bloque, este se utiliza como el cuerpo de la clase:

some_class = Class.new do def self.class_method puts “In class method” end def instance_method puts “In instance method” end end some_class.class_method obj = some_class.new obj.instance_method produce: In class method In instance method Por defecto, estas clases serán descendientes directos de Object. Se les puede dar un padre diferente pasándoles la clase del padre como un parámetro:

343

some_class = Class.new(String) do def vowel_movement tr ‘aeiou’, ‘*’ end end obj = some_class.new(“now is the time”) puts obj.vowel_movement produce: n*w *s th* t*m* Como Toman las Clases sus Nombres Usted puede haber notado que las clases creadas por Class.new no tienen nombre. Sin embargo, no todo está perdido. Si se asigna el objeto clase para una clase sin nombre a una constante, Ruby automáticamente nombra la clase después de la constante: some_class = Class.new obj = some_class.new puts “Initial name is #{some_class.name}” SomeClass = some_class puts “Then the name is #{some_class.name}” puts “also works via the object: #{obj.class.name}” produce: Initial name is Then the name is SomeClass also works via the object: SomeClass Podemos utilizar estas clases construidas dinámicamente para extender Ruby de maneras interesantes. Por ejemplo, aquí tenemos una reimplementación simple de la clase Ruby Struct: def MyStruct(*keys) Class.new do attr_accessor *keys def initialize(hash) hash.each do |key, value| instance_variable_set(“@#{key}”, value) end end end end Person = MyStruct :name, :address, :likes dave = Person.new(name: “dave”, address: “TX”, likes: “Stilton”) chad = Person.new(name: “chad”, likes: “Jazz”) chad.address = “CO” puts “Dave’s name is #{dave.name}” puts “Chad lives in #{chad.address}” produce: Dave’s name is dave Chad lives in CO

344

instance_eval y class_eval Los métodos Object#instance_eval, Module#class_eval y Module#module_eval permiten establecer self en un objeto arbitrario, evaluar el código en un bloque y luego reajustar self: “cat”.instance_eval do puts “Upper case = #{upcase}” puts “Length is #{self.length}” end produce: Upper case = CAT Length is 3 Estas formas también toman una cadena (pero véase el recuadro resaltado con algunas notas sobre los peligros de la evaluación de cadenas): “cat”.instance_eval(‘puts “Upper=#{upcase}, length=#{self.length}”’) produce: Upper=CAT, length=3

eval es del año pasado Usted puede haber notado que hemos estado haciendo una buena cantidad de metaprogramación --acceder a variables de instancia, definición de métodos y la creación de clases-- y todavía no hemos utilizado eval. Esto es deliberado. En los viejos tiempos de Ruby, el lenguaje carecía de muchas de estas funcionalidades de metaprogramación y eval era la única manera de lograr estos efectos. Pero eval viene con un par de inconvenientes. En primer lugar, es lento --la llamada a eval efectivamente compila el código en la cadena antes de ejecutarlo. Pero, peor aún, eval puede ser peligroso. Si hay alguna posibilidad de datos externos --cosas que vienen de fuera de la aplicación-- pueden terminar dentro de los parámetros a eval. Entonces tendríamos un agujero de seguridad, debido a que los datos externos pueden terminar conteniendo código arbitrario que la aplicación ejecutará a ciegas. eval ahora se considera un método de último recurso. Tanto class_eval como instance_eval establecen self para la duración del bloque. Sin embargo, difieren en la manera de configurar el entorno para la definición del método. class_eval prepara las cosas como si estuviera en el cuerpo de una definición de clase, por lo que las definiciones de método definen métodos de instancia: class MyClass end MyClass.class_eval do def instance_method puts “In an instance method” end end obj = MyClass.new obj.instance_method produce:

345

In an instance method En cambio, la llamada a instance_eval en una clase, actúa como si estuviera funcionando dentro de la clase singleton de self. Por lo tanto, cualquier método que se defina se convertirá en método de clase. class MyClass end MyClass.instance_eval do def class_method puts “In a class method” end end MyClass.class_method produce: In a class method Puede ser útil recordar que, a la hora de definir los métodos, class_eval e instance_eval tienen exactamente los nombres equivocados: class_eval define los métodos de instancia e instance_eval define los métodos de clase. ¡Que sabemos...! Ruby 1.9 introduce variantes de estos métodos. Object#instance_exec, Module#class_exec, y Module#module_exec se comportan de forma idéntica a sus contrapartes _eval pero toman sólo un bloque (es decir, no toman una cadena). Cualquier argumento dado a los métodos se pasan como parámetros de los bloques. Esta es una característica importante. Anteriormente, era imposible pasar una variable de instancia dentro de un bloque dado a uno de los métodos _eval --como self cambia por la llamada, estas variables salen del ámbito. Con la forma _exec, ahora se puede pasar: @animal = “cat” “dog”.instance_exec(@animal) do |other| puts “#{other} and #{self}” end produce: cat and dog

instance_eval y Constantes Ruby 1.9 cambió la forma Ruby de buscar constantes cuando se ejecuta un bloque mediante instance_eval y class_eval. Ruby 1.9.2 luego revertió el cambio. En Ruby 1.8 y Ruby 1.9.2, las constantes se buscan en el ámbito léxico en el que se les hace referencia. En Ruby 1.9.0, se buscan en el ámbito en el que instance_eval es llamado. En este ejemplo (artificial) se muestra el comportamiento en el momento de la última vez en que se hizo este libro --que bien podría haber cambiado de nuevo en el momento en que usted lo ejecute... module One CONST = “Defined in One” def self.eval_block(&block) instance_eval(&block) end end module Two CONST = “Defined in Two” def self.call_eval_block One.eval_block do CONST end end

346

end Two.call_eval_block

# => “Defined in Two”

En Ruby 1.9.0, este mismo código se evaluará a “Defined in One”.

instance_eval y Lenguajes de Dominio Específico Resulta que instance_eval tiene un papel fundamental que desempeñar en un determinado tipo de dominio específico del lenguaje (domain-specific language o DSL). Por ejemplo, podríamos escribir un simple DSL para gráficos de tortuga5. Para dibujar un conjunto de tres cuadrados de 5x5, podríamos escribir lo siguiente6: 3.times do forward(8) pen_down 4.times do forward(4) left end pen_up end Claramente, pen_down, forward, left y pen_up se pueden implementar como métodos Ruby. Sin embargo, para llamarles sin un receptor de esta manera, o tenemos que estar dentro de una clase que los define (o es un hijo de esa clase) o tenemos que hacer los métodos globales. instance_eval al rescate. Podemos definir una clase Turtle que defina los distintos métodos que necesitamos como métodos de instancia. También vamos a definir un método walk (recorrido) que ejecutará nuestra tortuga DSL, y un método draw para dibujar la imagen resultante: class def def def def def def def end

Turtle left; ... end right; ... end forward(n); ... end pen_up; .. end pen_down; ... end walk(...); end draw; ... end

Si implementamos walk correctamente, podemos escribir lo siguiente:

turtle = Turtle.new turtle.walk do 3.times do forward(8) pen_down 4.times do forward(4) left end pen_up end end turtle.draw 5 En los sistemas de gráficos de tortuga, puede imaginar que tiene una tortuga a la que puede ordenar avanzar n casillas, girando a la izquierda y girando a la derecha. También puede hacer que la tortuga suba y baje una pluma retráctil. Si la pluma baja, una línea dibujará el seguimiento de los movimientos posteriores de la tortuga. Muy pocas de estas tortugas existen en la naturaleza, por lo que se tienden a simular en los ordenadores. 6 Sí, el forward(4) es correcto en este código. El punto inicial se dibuja siempre. 347

Así que, ¿cuál es la implementación correcta de walk? Bueno, es evidente que tiene que utilizar instance_eval, porque queremos que los comandos DSL en el bloque, llamen a los métodos en el objeto tortuga. También tenemos que organizarlo para pasar el bloque dado al método walk para ser evaluado por la llamada instance_eval. Nuestra implementación es la siguiente: def walk(&block) instance_eval(&block) end Observar como capturamos el bloque en una variable y luego expandimos de nuevo la variable en un bloque en la llamada a instance_eval.

Daremos un listado completo del programa tortuga al final.

¿Es este un buen uso de instance_eval? Depende de las circunstancias. La ventaja es que el código dentro del bloque parece simple --no se tiene que hacer explícito el receptor: 4.times do turtle.forward(4) turtle.left end Hay un inconveniente, sin embargo. Dentro del bloque, el ámbito no es el que se cree que es, por lo que este código no funcionaría: @size = 4 turtle.walk do 4.times do turtle.forward(@size) turtle.left end end Las variables de instancia se buscan en self, y self en el bloque no es lo mismo que self en el código, que establece la variable de instancia @size. Debido a esto, la mayoría de las personas se están alejando de este estilo de bloque instance_evaled.

Métodos Gancho En la sección anterior de Macros y Módulos de Clase, se define un método llamado included en nuestro módulo GeneralLogger. Cuando este módulo se incluye en una clase, Ruby invoca automáticamente a este método included, permitiendo a nuestro módulo agregar métodos de clase a la clase anfitriona. included es un ejemplo de un método gancho (a veces llamado devolución de llamada). Un método gancho es un método que escribimos, pero que Ruby llama desde dentro del intérprete cuando ocurre algún evento determinado. El intérprete busca estos métodos por su nombre --si se define un método en el contexto adecuado con un nombre apropiado, Ruby lo va a llamar cuando suceda el evento correspondiente. Los métodos que se pueden invocar desde dentro del intérprete se muestran en la Figura 36 en la página siguiente. No vamos a discutirlos aquí --en su lugar, vamos a mostrar algunos ejemplos de uso. En la sección de referencia de este libro se describen los métodos individuales, y el capítulo Duck Typing, se describen los métodos de coerción con más detalle.

El Gancho Heredado Si una clase define un método de clase llamado inherited, Ruby lo va a llamar siempre que la clase sea una subclase (es decir, siempre que una clase hereda de la original).

348

Este gancho se usa a menudo en situaciones en que una clase base debe llevar un seguimiento de sus hijos. Por ejemplo, una almacenaje en línea puede ofrecer una variedad de opciones de envío. Cada una podría estar representada por una clase separada, y cada una de estas clases puede ser una subclase de una clase de envío única (la clase Shipping por ejemplo). Esta clase padre puede hacer un seguimiento de todas las opciones de envío diferentes mediante un registro de cada clase de estas subclases. Cuando llega el momento de mostrar las opciones de envío para el usuario, la aplicación puede llamar a la clase base para pedirle una lista de las hijas: class Shipping # Clase Base @children = [] # esta variable se encuentra en la clase, no en instancias def self.inherited(child) @children << child end def self.shipping_options(weight, international) @children.select {|child| child.can_ship(weight, international)} end end class def end end
 class def end end

MediaMail < Shipping self.can_ship(weight, international) !international FlatRatePriorityEnvelope < Shipping self.can_ship(weight, international) weight < 64 && !international

class InternationalFlatRateBox < Shipping def self.can_ship(weight, international) weight < 9*16 && international end end puts “Shipping 16oz domestic” puts Shipping.shipping_options(16, false) puts “\nShipping 90oz domestic” puts Shipping.shipping_options(90, false)

349

puts “\nShipping 16oz international” puts Shipping.shipping_options(16, true) produce: Shipping 16oz domestic MediaMail FlatRatePriorityEnvelope Shipping 90oz domestic MediaMail Shipping 16oz international InternationalFlatRateBox Los intérpretes de comandos suelen utilizar este modelo: la clase base mantiene un registro de los comandos disponibles, cada uno de los cuales se implementa en una subclase.

El Gancho method_missing Anteriormente, hemos visto cómo Ruby ejecuta una llamada a método mediante la búsqueda del método. Primero busca en la clase del objeto, después en su superclase, luego en la superclase de esa clase y así sucesivamente. Si la llamada al método tiene un receptor explícito, los métodos privados se omiten en esta búsqueda. Si el método no se encuentra en el momento en que nos quedemos sin superclases (debido a que BasicObject no tiene superclase), Ruby trata de invocar en el objeto original el método gancho method_missing. Una vez más, se sigue el mismo proceso --Ruby busca primero en la clase del objeto, entonces en su superclase, y así sucesivamente. Sin embargo, Ruby predefine su propia versión de method_missing en la clase BasicObject y por lo general, la búsqueda se detiene ahí. El método integrado method_missing básicamente plantea una excepción, ya sea un NoMethodError o un NameError dependiendo de las circunstancias. La clave aquí es que method_missing es simplemente un método Ruby. Podemos reemplazar en nuestras propias clases el manejo de las llamadas a métodos de otra manera indefinida en una forma específica de aplicación.

method_missing tiene una armadura simple, pero muchas personas se equivocan:

def method_missing(name, *args, &block) # ... El argumento name recibe el nombre del método que no se pudo encontrar y se pasa como un símbolo. El argumento args es una matriz con los argumentos que se pasaron en la llamada original. Y el argumento a veces olvidado block, recibe cualquier bloque que se pasó al método original. def method_missing(name, *args, &block) puts “Called #{name} with #{args.inspect} and #{block}” end wibble wobble 1, 2 wurble(3, 4) { stuff } produce: Called wibble with [] and Called wobble with [1, 2] and Called wurble with [3, 4] and # Antes de profundizar demasiado en los detalles, vamos a ofrecer un consejo acerca de la etiqueta. Hay dos principales maneras en que la gente usa method_missing. La primera intercepta cada uso de un método indefinido y lo maneja. La segunda es más sutil. Intercepta todas las llamadas pero sólo se ocupa

350

de algunas de ellas. En este último caso, es importante transmitir la llamada a una superclase, si se decide el no manejar en la implementación de method_missing: class MyClass < OtherClass def method_missing(name, *args, &block) if # manejar llamada else super # de lo contrario pasarlo end end end Si usted falla en pasar en las llamadas no manejadas, la aplicación ignorará las llamadas a métodos desconocidos en su clase.

Vamos a mostrar un par de usos de method_missing.

method_missing para Simular Accesores La clase OpenStruct se distribuye con Ruby. Esto permite escribir objetos con atributos que se crean dinámicamente por asignación. Por ejemplo, se podría escribir lo siguiente: require ‘ostruct’ obj = OpenStruct.new(name: “Dave”) obj.address = “Texas” obj.likes = “Programming” puts “#{obj.name} lives in #{obj.address} and likes #{obj.likes}” produce: Dave lives in Texas and likes Programming

Vamos a utilizar method_missing para escribir nuestra propia versión de OpenStruct:

class MyOpenStruct < BasicObject def initialize(initial_values = {}) @values = initial_values end def _singleton_class class << self self end end def method_missing(name, *args, &block) if name[-1] == “=” base_name = name[0..-2].intern _singleton_class.instance_exec(name) do |name| define_method(name) do |value| @values[base_name] = value end end @values[base_name] = args[0] else _singleton_class.instance_exec(name) do |name| define_method(name) do

351

@values[name] end end @values[name] end end end obj = MyOpenStruct.new(name: “Dave”) obj.address = “Texas” obj.likes = “Programming” puts “#{obj.name} lives in #{obj.address} and likes #{obj.likes}” produce: Dave lives in Texas and likes Programming Observe la forma de base de nuestra clase en BasicObject, una clase introducida en Ruby 1.9. BasicObject es la raíz de la jerarquía de objetos de Ruby y contiene sólo un número mínimo de métodos: p BasicObject.instance_methods produce: [:==, :equal?, :!, :!=, :instance_eval, :instance_exec, :__send__] Esto está bien, porque significa que nuestra clase MyOpenStruct será capaz de tener atributos tales como display o clase. Si en su lugar hubiéramos basado MyOpenStruct en la clase Object, entoncesestos nombres, junto con cuarenta y nueve más, habrían sido predefinidos y por lo tanto no daría lugar a method_missing. Observe también otro patrón común dentro de method_missing. La primera vez que referencia o asignar a un atributo de nuestro objeto, podemos acceder o actualizar los @valores hash adecuadamente. Pero también define el método que la llamada está tratando de acceder. Esto significa que la próxima vez que se utilice este atributo, se utilizará el método y no se invocará method_missing. Esto puede o no puede valer la pena dependiendo de los patrones de acceso a su objeto. También hay que notar cómo hay que saltar a través de unos aros para definir el método. Queremos definir el método sólo para el objeto actual. Esto significa que tenemos que poner el método en la clase singleton del objeto. Podemos hacer esto utilizando instance_exec y define_method. Pero eso significa que tenemos que utilizar el truco class << self para obtener la clase singleton del objeto. A través de una sutil implementación interesante, define_method siempre define un método de instancia, independientemente de si se invoca a través de instance_exec o class_exec. Sin embargo, este código revela la parte más oscura de la utilización de method_missing y BasicObject. Considere lo siguiente: obj = MyOpenStruct.new(name: “Dave”) obj.address = “Texas” o1 = obj.dup o1.name = “Mike” o1.address = “Colorado” produce: prog.rb:37:in ‘

’: undefined method ‘name=’ for nil:NilClass (NoMethodError)

352

El método dup no es definido por BasicObject, sino que aparece en la clase Object. Así que cuando se llama a dup, fue recogido por nuestro manejador method_missing, y justo retorna nil (porque no tenemos todavía un atributo llamado dup). Podríamos solucionar este problema para que al menos informe de error: def method_missing(name, *args, &block) if name[-1] == “=” # como antes... else super unless @values.has_key? name # como antes... end end Esta clase ahora informa de un error si llamamos en ella a dup (o a cualquier otro método). Sin embargo, todavía no podemos hacer dup o clone (o inspect, o convertir en una cadena, etc). Aunque BasicObject­parece algo natural para method_missing, puede ser más problemático de lo que parece­.

method_missing como Filtro Como muestra el ejemplo anterior, method_missing tiene algunos inconvenientes si se utiliza para interceptar todas las llamadas. Probablemente es mejor usarlo para reconocer ciertos patrones de llamada, pasando aquellas que no reconoce a la clase padre para su manejo. Un ejemplo de ello es la funcionalidad de buscador dinámico del módulo ActiveRecord de Ruby on Rails. ActiveRecord es la biblioteca de objeto-relacional en Rails --que permite acceder a bases de datos relacionales como si fueran depósitos de objetos. Una característica particular le permite buscar las filas que cumplen los criterios de ciertos valores dados en determinadas columnas. Por ejemplo, si a una clase Active Record denominada Book se la asigna una tabla relacional llamada books y esta incluye columnas llamadas title y author, se podría escribir lo siguiente: pickaxe = Book.find_by_title(“Programming Ruby”) daves_books = Book.find_all_by_author(“Dave Thomas”) Active Record no predefine todos estos métodos de búsqueda posibles. En su lugar, utiliza nuestro viejo amigo method_missing. Dentro de este método, busca las llamadas a métodos no definidos que coinciden con el patrón /^find_(all_)?by_(.*)/7. Si el método que se invoca no coincide con este modelo o si los campos en el nombre del método no corresponden a las columnas en la tabla de la base de datos, Active Record llama a super para generar un verdadero informe method_missing.

Un Último Ejemplo Vamos a reunir todos los temas de metaprogramación que hemos discutido en un último ejemplo, escribiendo un módulo que nos permita rastrear o trazar la ejecución de los métodos de cualquier clase mezclada en el módulo. Podríamos escribir lo siguiente: require_relative ‘trace_calls’ class Example def one(arg) puts “One called with #{arg}” end end ex1 = Example.new ex1.one(“Hello”)

# no trazar para esta llamada

class Example include TraceCalls

7

También busca para /^find_or_(initialize|create)_by_(.*)/.

353

def two(arg1, arg2) arg1 + arg2 end end ex1.one(“Goodbye”) puts ex1.two(4, 5)

# pero veamos el traceo de estas dos

produce: One ==> One <== ==> <== 9

called with Hello calling one with [“Goodbye”] called with Goodbye one returned nil calling two with [4, 5] two returned 9

Podemos ver de inmediato que hay una sutileza aquí. Cuando mezclamos el módulo TraceCalls en una clase, tiene que añadir el traceo para cualquier método de instancia existente en esa clase. También tiene que hacer arreglos para añadir el traceo de los métodos que se añadan posteriormente.

Vamos a empezar con el listado completo del módulo TraceCalls:

module TraceCalls def self.included(klass) klass.instance_methods(false).each do |existing_method| wrap(klass, existing_method) end def klass.method_added(method) # note: definición anidada unless @trace_calls_internal @trace_calls_internal = true TraceCalls.wrap(self, method) @trace_calls_internal = false end end end def self.wrap(klass, method) klass.instance_eval do method_object = instance_method(method) define_method(method) do |*args, &block| puts “==> calling #{method} with #{args.inspect}” result = method_object.bind(self).call(*args, &block) puts “<== #{method} returned #{result.inspect}” result end end end end Al incluir este módulo en una clase, se invoca al método gancho included. En primer lugar, utiliza el método de reflexión instance_methods para encontrar todos los métodos de instancia existentes en la clase anfitriona (el parámetro false límita la lista a los métodos en la propia clase, y no en sus superclases). Para cada método existente, el módulo llama a un método de ayuda, wrap, para añadirle algo de código de traceo. Vamos a hablar de wrap en breve.

A continuación, el método included utiliza otro gancho, method_added. Este es llamado por Ruby

354

cuando se define un método en el receptor. Hay que tener en cuenta que se define este método en la clase que se pasa al método included. Esto significa que el método será llamado cuando los métodos son añadidos a esta clase anfitriona y no en el módulo. Esto es lo que nos permite incluir TraceCalls al principio de una clase y luego añadir los métodos de esa clase --todas las definiciones método serán manejadas por method_added. Ahora observe el código dentro del método method_added. Tenemos que lidiar con un potencial problema. Como se ve cuando nos fijamos en el método wrap, se añade el seguimiento de un método creando una nueva versión del método que llama al antiguo. Dentro de method_added, se llama a la función wrap para añadir este trazado. Pero dentro de wrap, vamos a definir un nuevo método para manejar este envoltorio y la definición va a invocar al method_added otra vez, y entonces se llama de nuevo a wrap y así sucesivamente, hasta que la pila se agote. Para evitar esto, se utiliza una variable de instancia y se hace el envoltorio sólo si no lo hemos echo ya. El método wrap toma un objeto de clase y el nombre de un método a envolver. Busca la definición original de este método (con instance_method) y lo guarda. A continuación, redefine este método. Este nuevo método produce salidas de trazado y luego llama al original, pasandole los parámetros y el bloque desde el envoltorio8. Fíjese en cómo se llama al método vinculando el método objeto a la instancia actual y luego invocando ese método vinculado. La clave para entender este código y la mayoría de código de metaprogramación, es seguir los principios básicos que hemos elaborado al comienzo de este capítulo --como self cambia como se llama a los métodos y se definen las clases y cómo se llama a los métodos mediante su búsqueda en la clase del receptor. Si se queda atascado, haga lo que hacemos nosotros y dibuje pequeñas cajas y flechas. Creemos que es útil seguir con la convención que se utiliza en este capítulo: los vínculos de clase van a la derecha y los vínculos de superclase arriba. Dado un objeto, una llamada a método es entonces una cuestión de encontrar el objeto receptor. Se va a la derecha una vez y luego siguiendo la cadena de superclase hacia arriba es por dónde tiene que ir.

Entorno de Ejecución de Nivel Superior Por último, hay un pequeño detalle que tenemos que cubrir para completar el entorno de la metaprogramación. Muchas veces en este libro hemos afirmado que todo en Ruby es un objeto. Sin embargo, hemos utilizado una y otra vez lo que parece contradecir esto --el entorno de ejecución de alto nivel de Ruby: puts “Hola, Mundo” No hay objeto a la vista. Nosotros, bien podríamos haber escrito alguna variante de Fortran o Basic. Sin embargo, cavando más profundo, nos econtraremos con objetos y clases que acechan en el más simple código. Sabemos que el literal “Hola, Mundo” genera un String de Ruby, por lo que es un objeto. También sabemos que la pelada llamada al método puts es efectivamente lo mismo que self.puts. Pero, ¿qué es self? self.class # => Object En el nivel superior, estamos ejecutando el código en el contexto de algún objeto predeterminado. Cuando definimos los métodos, en realidad estamos creando (privadamente) métodos de instancia para la clase Object. Esto es bastante sutil, ya que como están en la clase Object, estos métodos están disponibles en todas partes. Y ya que estamos en el contexto de Object, podemos utilizar todos los métodos de Object (incluidos los mixtos desde Kernel) en forma de función. Esto explica por qué podemos llamar a métodos Kernel tales como puts en el nivel superior (y de hecho a lo largo de todo Ruby), y es porque estos métodos son parte de cada objeto. Las variables de instancia de nivel superior también incumben a este objeto de nivel superior. La metaprogramación es una de los más agudas herramientas de Ruby. No hay que tener miedo de usarla para elevar el nivel en que se programa. Pero al mismo tiempo, hay que usarla sólo cuando sea necesario --demasiadas aplicaciones metaprogramadas pueden llegar a ser bastante oscuras rápidamente. 8 La capacidad de un bloque de tomar un parámetro de bloque fue introducido en Ruby 1.9. 355

El Progama de Gráficos Tortuga #--# Excerpted from “Programming Ruby 1.9”, # published by The Pragmatic Bookshelf. # Copyrights apply to this code. It may not be used to create training material, # courses, books, articles, and the like. Contact us if you are in doubt. # We make no guarantees that this code is fit for any purpose. # Visit http://www.pragmaticprogrammer.com/titles/ruby3 for more book information. #--class Turtle # directions: 0 = E, 1 = S, 2 = W, 3 = N # axis: 0 = x, 1 = y def initialize @board = Hash.new(“ “) @x = @y = 0 @direction = 0 pen_up end def pen_up @pen_down = false end def pen_down @pen_down = true mark_current_location end def forward(n=1) n.times { move } end def left @direction -= 1 @direction = 3 if @direction < 0 end def right @direction += 1 @direction = 0 if @direction > 3 end def walk(&block) instance_eval(&block) end def draw min_x, max_x = @board.keys.map{|x,y| x}.minmax min_y, max_y = @board.keys.map{|x,y| y}.minmax min_y.upto(max_y) do |y| min_x.upto(max_x) do |x| print @board[[x,y]] end puts end end private

356

def move increment = @direction > 1 ? -1 : 1 if @direction.even? @x += increment else @y += increment end mark_current_location end def mark_current_location @board[[@x,@y]] = “#” if @pen_down end end turtle = Turtle.new turtle.walk do 3.times do forward(8) pen_down 4.times do forward(4) left end pen_up end end turtle.draw produce: ##### # # # # # # #####

##### # # # # # # #####

##### # # # # # # #####

357