Talk Like A Duck

Trap Number 1: Confusing Calling Interface with Class

Seeing a[2] and thinking Array is an example of this. Just because 99% of the time when you see something "indexed" by an integer, that thing doesn't have to be an Array. It might be an Array, but it could be a Hash, or an ActiveRecord class, or anything which implemented some form of [] method. This is looking at the method invocation as a 'cover.'

Ruby method signatures are quite a bit more flexible or at least different from those of other languages, something which can trip up someone trying to see Ruby from the perspective of their 'native' language. Consider the varieties of parameters which can be passed to Array#[], or String#[], rather than just a indexing methods these can slice and dice the receiver in various ways

Although different classes might all implement a [] method, and while there are likely similarities or common subsets of functionality, each has it's own quirks. This can drive folks expecting type signatures nuts, but it's actually one of the things which gives Ruby it's power, and efficiency of expression.

Some folks go to great efforts trying to pin-down Ruby and make it 'behave' like other languages, but that's a fools errand which works against Rubys strengths. I'd recommend that these folks redirect their efforts towards improving their testing skills.

Trap Number 2: Ignoring the Contents

For better or worse, many Ruby classes provide functions which may not work for all instances. For example, the Range (1..10) is enumerable while (1.0..10.0) is not. This is because some of the methods in range expect the beginning and ending values of the range to implement methods such as #succ in order to determine the next value. Further they implicitly expect that applying #succ successively will get to the end value.

So does this mean that making the range (1.0..10.0) is ilicit or bad? Not if you don't need to enumerate it and only want to do things like check whether or not a value is included in the range.

Some folks on ruby-talk have expressed the opinion that the documentation for Range implies that (1.0-10.0) is not a valid range, because the scope of the requirement for elements to implement #succ is ambiguous. Pragmatically I find the ability to construct enumeration challenged ranges useful.

Further if you take the philosophy which leads to restricting ranges to elements which make the ranges enumerable consider these things:

%w(Now is the time).sort      # Works fine
[:fee, :fie, :foe, :fum].sort # Fails 
['fred', 42].sort             # Fails

Now do we really want to outlaw arrays of symbols, or heterogeneous arrays from Ruby usage because they don't sort?

What do you think?

Closures

The general meaning of the term closure in computer science is a function which captures one or more variable bindings in effect at the time it was created. Closures are created in Ruby using lambda or its alias proc:

irb(main):001:0> def closure(a)
irb(main):002:1>   lambda {a}
irb(main):003:1>   end
=> nil
irb(main):004:0> cl1 = closure(1)
=> #<Proc:0xb7b3cf10@(irb):2>
irb(main):005:0> cl2 = closure(2)
=> #<Proc:0xb7b3cf10@(irb):2>
irb(main):006:0> cl1.call
=> 1
irb(main):007:0> cl2.call
=> 2

Notice that the block in line 2 refers to the method parameter a, and returns the value of a as the blocks value. The Kernel#lamba method turns the block into a Proc object which is returned as the value of the call.

in lines 4 and 5 we make two calls to the method closure with different arguments, and save the resultant closures in cl1 and cl2 respectively.

Notice that when we call each closure in lines 6 and 7, each one returns the value passed to cont when that closure was created.

Continuations

The mystical aspect of continuations is that they allow us to jump back into the middle of the execution of a method which has already returned:

irb(main):008:0> def continuation
irb(main):009:1>   i = 0
irb(main):010:1>   lola = nil
irb(main):011:1>   callcc {|cc| puts "In callcc";lola = cc}
irb(main):012:1>   puts "i is now #{i}"
irb(main):013:1>   i += 1
irb(main):014:1>   lola
irb(main):015:1>   end
=> nil
irb(main):016:0> cont = continuation
In callcc
i is now 0
=> #<Continuation:0xb7b727a0>
irb(main):017:0> cont.call
i is now 1
=> #<Continuation:0xb7b727a0>
irb(main):018:0> cont.call
i is now 2
=> #<Continuation:0xb7b727a0>                             

Line 10 makes the ruby interpreter see that lola is a local variable of the method and so the block can set it and the method can return it.

Note that the call to the continuation method in line 16 is the only time we actually evaluate callcc and the block. The call to callcc returns and the rest of the continuation method is excuted and the method returns.

Each time we call the continuation referenced by the variable cont, we execute the code afer the callcc which created it. It acts like a closure in a sense since it captures the last state of the variables i and lola each time. But this is because the continuation represents a particular execution state which includes not only the variebles in scope at that time, but also the program counter.

FLASH Breaking News: Rick has a Ruby Red Face

Robert Dober pointed out that if you run the above code in ruby rather than in irb it loops on the first cont.call, printing out:

i is now 1

i is now 1

i is now 1

ad infinitum (or at least ad ctrl-C)

I was actually abusing continuations, since in general they aren’t meant to be reused. I’ll write a new posting in the near future on how continuations are used in the Ruby standard library Generator class, In the meantime, here’s a simpler example which runs in ruby without trying to reuse the continuation:

def continuation
  puts "Before callcc"
  callcc {|lola| puts "In callcc";return lola}
  puts "After callcc"
enddef continuation

  puts "Before callcc"

  callcc {|lola| puts "In callcc";return lola}

  puts "After callcc"

end

puts "Begin"

cont = continuation

puts "Got cont #{cont.inspect}"

if cont

  cont.call

  puts "After call"

end

puts "All done"

If we run this using ruby we see:

$ ruby testcontin.rb
Begin
Before callcc
In callcc
Got cont #<Continuation:0xb7de3840>
After callcc
Got cont nil
All done

Continuations in other disciplines

Another explanation

Q: Do all inheritance chains and all objects have a homologue
> metaclass at all times, which are behind the scenes?

In ruby metaclasses are singleton classes of classes. Just as a class
holds the table used to find the methods of its instances, the
metaclass holds the table used to find methods for its sole instance
i.e. the class.

The singleton class which serves as the metaclass of a class is
created when the class is created. This is done internally by the
Ruby interpreter.

While object’s don’t have metaclasses they can have singleton classes,
which are created when needed, e.g. when you do something like:

 a = "abc"
 b = "def"

 def a.method
 end # singleton class for the object referenced by a is created now

 class <<b #singleton class for the object referenced  by b is created now
 end

Q: Do a chain of metaclasses spontaneously appear at the moment when a class is used as a receiver : so to be used to call a method inside of a parentclass?

No, as I just said, metaclasses are created along with their
corresponding class. The metaclass’ superclass is set to the
metaclass of the classes superclass.

Since I first wrote this I’ve gotten some feedback that the last sentence is a little hard to digest, so here’s an example. Let’s say we create a class MyNiftyClass as a subclass of Object. The singleton class of the class object referenced by the MyNiftyClass global gets created at the same time as class object, no waiting for one of the things which trigger the creation of a singleton class for a non-class object. Thesuperclass of the MyNiftyClass is set to object, and the superclass of MyNiftyClass’ metaclass is set to Object’s metaclass.

Besides the fact that their creation occurs immediately, there is one other difference between
singleton classes of objects and singleton classes used as
metaclasses. The later can have subclasses, while the former cannot.

Normal object singleton classes have their internal superclass set to
the original class of the object.

Note that I’m using superclass and class here to describe the internal
relationship. Ruby’s class and superclass methods don’t always give a
true picture when singleton/metaclasses are involved. I personally
think of the class-like objects linked together with the superclass
field as a behavior chain since it’s used to implement the behaviour
of one or more objects.

Q: How can a metaclass contain more methods than its corresponding class has. Can you give an example of the code in the next addition(sic)?

The number of methods in the class and the number of methods in the
metaclass is completely independent, for example, look at the
following and compare it to what I said in reponse to question #1

class MyClass

  def initialize # This defines the initialize method in MyClass which
                   # Like all such methods are available to INSTANCEs
                   # of the class, and its subclasses
  end

  def method1 # another instance method
  end

  def MyClass.class_method # This defines a class method in the
                                   # singleton class of MyClass (i.e. the metaclass)
                                   # which is available to instances of the
                                   # metaclass and its subclasses
  end

  def self.class_method_2 # This adds another class method, it's
                                # Just a different syntax for the last form of
                                # definition since within the scpe of a class
                                # definition, self is bound to that class
  end

  class << self   # or equivalently class << MyClass
                     # Now we are in an inner scope, that of MyClass' metaclass

     def class_method_3  # So this also becomes a class method
                              # of MyClass
     end
end

So MyClass has two instance methods (plus those it inherits from
Object) and three class methods (plus those the metaclass inherits from
Object’s metaclass.

As a related note, when a class includes a Module, another kind of
virtual class is inserted between the class and it’s superclass. This
virtual class (or I_Class) looks like a class but has a pointer to the
method table of the module instead of having its own table. This
lets modules appear in different behavior chains and lets those
including them see updates to the module when they are made. There
are some other fields of the module which are also copied, but I’m not
going to mention them here since they aren’t relevant and might
confuse.

Q: Which is searched first in the inheritance chain. methods in
the proper parents, or methods in the meta parents?

There’s no cross over at all. When finding a method for an object,
Ruby gets the head of what I called the behavior chain. For a normal
object with no singleton class, this will be the class, For an object
with a singleton class this will be the singleton class. If the
method is found, then it’s used, if not the next class-like thing in
the behavior chain is examined and so forth. The keyword super makes
the search start in the next link in the behavior chain after the one
in which the current method was found.

So if you’re invoking a method on a normal object, no metaclasses will
be on the chain. If you are invoking a method on a class, then the
behavior chain will consist of metaclasses, except that the superclass
of Object’s metaclass is Class. If you think about this hard enough it
makes sense, since the instance methods of Class are for use by
classes.

So if we have:

class B
       ...
end

b = B.new
b.to_s

The search goes:

B → Object → (I_Class wrapper for Kernel)

the last is because Object includes Kernel

and

   B.new

the search goes

(singleton of B) → (singleton of Object) → Class → Module →Object → (I_Class wrapper for Kernel)

Q: If a method is found is the search stopped even though another method with the same name might exist in a parallel chain?

As I just described, the parallel chain is irrelevant, it isn’t
considered at all.