Chain, Chain, Chain

Posted by Rick DeNatale Sat, 02 Jun 2007 22:28:00 GMT

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:
  1. Current instance, followed by class methods
  2. Mixed in methods
  3. Superclass instance (repeat 1)
  4. 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

Read more...

Posted in ,  | Tags , ,  | 1 comment

Power, Responsibility and Tricksy VM Implementers

Posted by Rick DeNatale Thu, 15 Mar 2007 12:05:00 GMT

In a ruby-talk discussion of the pleasures and perils of adding to or changing core ruby classes. A practice denigrated as “monkey patching” by some, but embraced as a powerful technique, when practiced with care, by others. Someone just reported an experiment involving changing a basic core method:
 Fixnum.class_eval do
   def +(number)
     self - number
   end
 end

The result: It blew up his irb.

Ruby certainly gives a lot of power. A little, and in some cases a lot, more than most popular OO languages. Read on..

Read more...

Posted in ,  | Tags , ,  | 1 comment

Boolean Implementations, Ruby, Smalltalk and self

Posted by Rick DeNatale Tue, 10 Oct 2006 16:43:00 GMT

The topic of defining a new ruby class which could have instances that, like false and nil were seen as a boolean which was not true, just came up on ruby-talk.

This has come up before, and it turns out that in Ruby being untrue is reserved to these two specific instances.

The boolean test is pretty deeply engrained into the implementation of ruby. The actual test seems to be defined in the RTEST macro in ruby.h
#define Qnil   ((VALUE)4)
#define RTEST(v) (((VALUE)(v) & ~Qnil) != 0)

Which means that any object whose reference VALUE has any bit set other than the 3rd LSB is true.

In ruby, the control flow statements like ‘if’ aren’t messages, but are ‘compiled’ into a direct test and conditional branch.

Even Smalltalk, which defined even if/then/else as a message, e.g.
    booleanValue ifTrue:[Transcript show:'true'] ifFalse: [Transcript show:'false']
Tended to cheat in the implementation… Read more...

Posted in ,  | Tags , ,  | 2 comments | no trackbacks

Performance Anxiety

Posted by Rick DeNatale Tue, 26 Sep 2006 19:17:00 GMT

I've been meaning to write about Ruby performance for a while, and a recent blog post by an old friend and colleague, got me off my proverbial.

The old friend is John Duimovich, who wrote about the relative performance of C++ and Smalltalk and what that could mean for ruby.

John's message is important for those who bemoan the performance of Ruby, and I plan to expand on that message in this and later posts to this blog, but first a few words about Mr. Duimovich.

Read more...

Posted in ,  | Tags , , , ,  | 10 comments | no trackbacks

On Variables, Values, and Objects

Posted by Rick DeNatale Wed, 13 Sep 2006 19:47:00 GMT

I’ve recently observed some posts to ruby-talk which evidence some confusion on the part of the posters about the relationship between variables and objects in Ruby. One currently active thread concerns several participants who are upset that instances of the Matrix class in the Ruby standard library can’t be changed once created.

In Ruby, like in other uniformly object-oriented languages, the relationship between variables and their values is subtly different than in other languages, and this is a crucial paradigm shift, which must be crossed in order to understand Ruby.

In many languages a variable names an area in memory which holds a “bag-of-bits” representing the value of the variable. The size of that area depends on the type of the variable. A variable holding an integer might be 4-bytes long, while one holding a particular structure might be 325 (or whatever) bytes.

In a uniformly object-oriented language, all variables reference objects, and any variable can reference any object, or different objects over time. My good friend at IBM, the late David N. Smith, used to say that in such a language, “all variables are the same size,” when he wrote about or taught Smalltalk.

This distinction can trip up the unwary. Let’s try to clear some of the stumbling blocks out of the way.

Read more...

Posted in ,  | Tags , , , , ,  | no comments | no trackbacks