Talk Like A Duck: Category ruby_for_nubys

You Can't Judge a Book... Some Mental Traps in Learning Ruby

Rick DeNatale — Wed, 17 Oct 2007 13:01:00 -0400

Quick, in the Ruby expression:

a[10]

What's the class of a?

Many beginning, and intermediate, rubyists whould instinctively say Array! The real answer is that given just this code, you don't know.

Recently, on the rails-talk mailing list there was a discussion of this idea from Jamis Buck. Jamis uses alias_method in ActiveRecord::Base so that he can use shortcuts like:

Person[1]

as a shortcut for:

Person.find(1)

This is particularly nice when playing with ActiveRecord in the rails console, but many seem to think that this should be made part of Rails core, and I don't see a real objection.

Now one objection raised by the folks who answer Array to the opening question is that, since ActiveRecord rows can be deleted, Person[2] might fail even though Person[1], and Person[3] work. The reasoning is that the [] makes it "look like an array" and arrays don't act like that.

To me this is a case of judging a book by looking at it's cover. Something which I strongly suggest needs to be resisted in order to achieve ruby mastery.

Let's have a look at a couple of "can't see past the cover" traps in Ruby.

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?

Ahh, the Subtleties of Ruby's Operator Precedence

Rick DeNatale — Tue, 07 Aug 2007 15:24:00 -0400

Not long ago while working on an existing Rails application, (i.e. code I hadn’t written). I was mystified when a logical expression seemed to be returning an odd result. The expression had been written with not, and, and or, and was the right hand side of an assignment statement. ventually I changed to using !, &&, and || which fixed the problem. I never completely understood what was going on, until I encountered this blog entry by Jay Fields.

One of the big differences between Ruby and Smalltalk is the use of operator precedence. In Smalltalk, the grammar is very simple, unary message selectors bind tighter than binary selectors, which bind tighter than keyword selectors. The assignment operator binds more loosely than any of these. This is often a stumbling block for newcomers to Smalltalk when they find that in Smalltalk 3 + 5 * 2 evaluates to 16.

Ruby in comparison has quite a rich and flexible syntax. Usually, it’s quite intutitive, but, depending on where you come from there can be some surprises.

I understood the relative precendences of, say && vs. and in Ruby, but the fact that and had weaker precedence than = escaped me, until Jay’s article turned the light on for me.

As they say, you learn something new everyday, or at least you hope you do. I don’t expect that I’ll forget this little corner of Ruby in future

Polishing That Chain

Rick DeNatale — Tue, 12 Jun 2007 17:22:00 -0400

A few days back I wrote this:

The metaclass’ superclass is set to the metaclass of the classes superclass.

Since I first wrote it I’ve gotten some feedback that the last sentence is a little hard to digest, so I’ve added 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.

I’ve gone back and editted the original post, but I’ve summarized it here in case anyone else has actually already read it.

Update on Continuations

Rick DeNatale — Wed, 06 Jun 2007 17:00:00 -0400

Robert Dober discovered that the continuation example which I gave in last night’s article behaves badly if you run it with ruby rather than irb.

I’ve made note of this in the original article, and I’ve added a simpler example which does work under ruby. I’ll try to come back with a new article which shows an example of how continuations are normally used.

Closing in on Closures and Jumping into Continuations

Rick DeNatale — Tue, 05 Jun 2007 21:41:00 -0400

Recently on ruby-talk someone asked if continuations and closures were the same thing.

They are related in that they both are tied to a particular point in time in the execution of a program. The difference is that closures are like a souvenir of a trip, while continuations are like a kind of time-machine.

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

A continuation, on the other hand, represents a particular point of execution, not [just] variable bindings. When a continuation is called, it acts like (the dreaded) goto, we jump to the point right after the creation of the continuation. In Ruby we create a continuation with the Kernel#callcc method. This method takes a block and yields it a new continuation object.

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

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"
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

You might get a sense of deja-vu from this discussion of continuations since a similar idea pops up in the movies from time to time. Two examples which come to mind are the American movie “Groundhog Day,” and the German movie “Lola rennt” or in English, “Run Lola, Run.”

Another explanation

SamRuby this explanation of continuations a couple of years ago. It’s valuable as a companion to this article since it has a somewhat different approach. I do have a quibble with Sam in that I don’t agree with his statement that a closure is a “continuation’s more general cousin.” Some continuations are, or act a little like, closures, but closures aren’t continuations since they lack the aspect of holding a point of executioncont

Chain, Chain, Chain

Rick DeNatale — Sat, 02 Jun 2007 18:28:00 -0400

I’ve noticed some confusion lately on the part of some newcomers to Ruby about how methods are found at runtime, and in particular, the relationship between instance and class methods.

A week or so ago, someone posted some questions on ruby-talk about this issue, and then today I ran across this blog review of David Black’s “Ruby for Rails” which contained this:

On every method call, Ruby will search its object space in the following order:

Current instance, followed by class methods

Mixed in methods

Superclass instance (repeat 1)

Object methods, followed by Kernel mixin

I often get confused with mixin, class, and instance method precedence, so this is a useful model to revisit and keep in mind.

I don’t know where that reference to class methods in item 1 came from. I don’t think David said that in his book.

Here’s how it really works

Here in the form of answers to the questions posed on ruby-talk last week is my explanation of how Ruby finds methods when a message is sent to an object

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.