Talk Like A Duck: Tag variables

Whose Variable Is It Anyway?

Rick DeNatale — Fri, 08 Feb 2008 16:14:00 -0500

The more I think about Ruby in relation to other object programming languages I’ve worked with, the more I realize that there’s a continuum of static vs. dynamic typing.

Ruby fits close to one end of that continuum. Understanding this can help understand how to best use the language. I recently had a quick look at Russ Olsen’s new book Design Patterns in Ruby and looked at his section on the observer pattern. I’d just posted to ruby-talk about this pattern, how it was implemented in Smalltalk, and a more Rubyish implementation. I’ll get to that at the end of this article, but first I really feel the urge to talk about instance variables.

If we view a type as a particular interpretation of a memory layout, I see something like this

Language	Outside	inside
Java	static	static
Smalltalk	encapsulated	static
Ruby	encapsulated	dynamic

The two columns represent how the object’s innards “look” from outside the object, and inside the object (i.e. inside a method) respectively.

In Java, subject to access modifiers, instance variables, a.k.a. fields, can be directly accessed. No accessor method is required. In Smalltalk and Ruby, instance variables of an object are only accessible while executing one of the object’s methods. Although both languages provide a bypass mechanism, instance_variable_get and instance_variable_set for Ruby; instVarAt: and instVarAt:put: for Smalltalk, these are both methods, and are to be used only in “emergencies” since they break the encapsulation of the object.

Static Instance Variable Binding

By static here, I mean that the code which accesses the instance variable uses information which is statically bound by the compiler. This is a subtlety which misses a lot of today’s programmers who don’t understand what a compiler does, which is to take the textual, human written and readable source code and turn it into bits and bytes which can be executed by some form of computer. The older wiser guys might just want to skim this section.

That computer might be a real computer, like an Intel processor, or a virtual computer in the form of a software implemented virtual machine or interpreter. In the case of a real or virtual machine, there is an instruction set which gives the repertoire of the machine. The program is executed by moving step by step, instruction by instruction. Now, if we have a simple C statement like:

int a = b

Then the instruction sequence for an imaginary computer might be something like:

    load  reg2, 20(reg1)
    store reg2, 40(reg1)

Which loads the second machine register from a word which is at an address 20 bytes after the address contained in machine register 1, and then stores that value into another word offset 40 bytes from register 1. Here a and b are intended to be local temporary variables, and I’ve decided that my compiler is using register 1 to point to the current activation stack frame. Those magic numbers, 20 and 40 are computed by the compiler as part of it’s function to map variables to memory locations.

The idea that instructions might be different lengths is quite common in instruction set design. Usually some number of bits at the beginning of the instruction is used to encode an ‘op code’ like load or store, add, or subtract, etc. Other bits are used to determine the presence and format of parameters for the operation. Different instruction sets have different addressing modes, which allow memory to be addressed in various ways, such as the mode used above which addresses memory as an offset from a location held in a register. Other addressing modes might add another register used to index elements in an array, for example. Most real instruction sets have some unit of length for instructions, so for a given machine architecture, all instructions might be one or more words, or one or more bytes.

Bytecodes Are An Instruction Set Format

The term “bytecode” is simply a particular form of an instruction set, or rather a family of forms. Most people associate the term with Java, and a particular instruction set, although the term predates Java, being used by Smalltalk and probably before. It really means that the ‘machine code’ instructions are represented as a series of bytes. Many instructions are encoded by a single byte, although some require additional bytes in order to form a complete instruction. The general term bytecode simply means that the length unit for the instruction set is one byte.

Although Java and Smalltalk implementations typically use bytecode instruction sets for their virtual machines, the actual set of bytecodes differs, much as the instruction set for an Intel Core Duo 2, differs from the instruction set for a PowerPC G4.

Classical Instance Variable Binding, Smalltalk Style

Now lets look at similar code in Smalltalk. In this article, I’m using the bytecodes defined by the out of print, “Smalltalk:The Language and Its Implementation”, a.k.a. “The Blue Book”, other Smalltalk implementations might be slightly different.

Let’s say that a and b here are instance variables. The Smalltalk bytecodes

    a := b

Would look something like:

    push_iv_4            # push instance-variable #4 
                             # onto the stack
    store_and_pop_iv_6   # store the top of the stack in
                             # instance-variable #6

In Smalltalk, those magic index numbers used to access instance variables are determined when the class definition is saved. In this case b turned out to be the 4th instance variable, and a the 6th. Smalltalk bytecodes are optimized for small objects, the first 16 instance variables can all be pushed or popped with a single-byte instruction, if an object has more than 16 instance variables then those beyond the 16th need to be accessed via an extended push or store instruction, which allows up to 64 instance variables to be accessed.

In Smalltalk, although instance variables aren’t typed, they are declared in a class definition message executed when the class definition is saved. Any time a class definition is saved, the indices for the instance variables of that class, and of any subclasses are (re)computed, and any methods in the class and it’s subclasses are re-compiled to adjust the offsets. The instance variables defined in the topmost class get the first n offsets, each immediate subclasses instance variables get sequential offsets starting with the next available, and so forth.

This is why I said above that inside a Smalltalk object, i.e. within it’s methods, the object is mapped statically. Changing the instance variable definitions requires re-compilation to avoid ‘type-errors’ in the methods.

Note that those ‘emergency-only’ methods instvarAt: and instVarAt:put: map to the push_iv and store_and_pop_iv bytecodes, the first argument to both is the instance variable index. This also means that they need to be used with care, since you need to know the offset of the instance variable. Now, at least Smalltalk can tell you if you try to access a non-existant instance variable slot but it can’t tell that you’re accessing the wrong slot.

Java Field Binding

In Java, offsets are not compiled directly into the bytecodes, there’s a level of indirection. Peter Haggar, with whom I used to work at IBM wrote an article on Java bytecodes on developerworks. I hope he won’t mind if I borrow one of his examples. Here’s a simple accessor method

public String employeeName()
{
    return name;
}

And the resultant bytecodes. (The 0, 1, and 4 are offsets from the beginning of the method)

    Method java.lang.String employeeName()
    0 aload_0
    1 getfield #5 <Field java.lang.String name>
    4 areturn

What this code does first is to push a reference to the current object, this, onto the stack. Then the getfield instruction uses it’s operand to replace the top two items on the stack with the value of the field. So these two byte-codes (actually 3 bytes in total) are roughly equivalent to the Smalltalk push_iv bytecode, but for two differences:

The Smalltalk push_iv opcode implicitly uses the receiver of the current method, whereas the getfield opcode needs another argument referencing the object whose instance variable is being accessed.
In Smalltalk the argument identifying the variable is an integer index, but in Java the argument is actually a reference to a field descriptor associated with the class of the object whose instance variable is being referenced.

The first difference is because in Java, unlike in Smalltalk, you can directly get and set public fields outside of of the objects methods, so since the object in question isn’t implied, it has to be specified.

The second difference is to allow for separate compilation. The actual Java VM specification doesn’t dictate how fields are mapped within objects, but the abstraction is to allow this mapping to be adjusted at the time classes are loaded. If a subclass is compiled separately from it’s superclass, it might get a new starting position for it’s fields everytime it’s loaded if one or it’s superclasses has added or removed fields.

So in order to access a Java field, the compiler needs to know the type of the object containing the field. This is true whether we are inside a method or outside.

Instance Variables, The Ruby Way

In Ruby, instance variables aren’t declared, so offsets can’t be assigned statically. Instead, Ruby looks up instance variables dynamically, using the instance variable name rather than an offset. Again this matches the ‘emergency use’ messages, instance_variable_get and instance_variable_set take an instance variable name, complete with the ”@” sigil, where the Smalltalk instVarAt: methods take an integer.

In Ruby 1.8, this lookup is implemented in a fairly straightforward fashion. With a few exceptions, which I won’t take the time to go into here, a Ruby object has a pointer named iv_tbl which points to a hash table which maps the instance variable names to values. In Ruby 1.9, the implementation is a bit more clever, but the effects are the same.

So Whose Variable IS it Anyway?

Which brings us back to the title of this article. In Java and Smalltalk, every instance of a given class has the same set of instance variables, albeit each with it’s own value. The variables come into existence when they are declared, and the class is compiled or the class definition is saved.

One thing I didn’t mention in the discussion of Smalltalk is that, because traditional Smalltalk implementations don’t separate the development environment from the run-time environment, when a class definition changes, besides requiring method recompilation for the class and it’s subclasses, any existing instance variables need to be mutated to either add or remove the changed instance variables. Back when he was working on the language self, which has dynamic resolution of instance variables like Ruby, Dave Ungar used to like to kill various Smalltalk implementations by adding an instance variable to the Object class. The problem is that because we are trying to operate on the running system, the system usually trips over itself during such a change. I tried this a few weeks ago with Squeak, and although it warned me twice that I shouldn’t do that, it did try when I clicked that second “Are you sure” button, and crashed pretty quickly. Ruby does handle this as a matter of course, since instance variables are only added to individual objects when they are needed, and self inside a method really is duck-typed, actually more than duck-typed, since the needed instance variables appear just in time.

So you mentioned the Observer Pattern, What’s All This Have To Do With That

One of the things which got me thinking about this again was a thread on ruby-talk some weeks ago about Ruby garbage collection and some of the things which keep Object from being considered garbage and being collected. The Ruby GC tends to have problems if you use finalization and aren’t really careful about how you define your finalizers.

One of the classic gotcha’s in Smalltalk in this vein is the implementation of Object dependents, a.k.a. the Observer Pattern. Smalltalk provides a mechanism to add dependent objects to any other object which, when it want’s to notify it’s dependents that it has changed, can simply send itself the changed message, which in turn sends each dependent the message update: with the changed object as the argument.

This is the basis of the Model View Controller design in Smalltalk. Views register as dependents on Models, and when a model changes, any Views depending on it can react. This is the genesis of the Observer pattern from the well known gang of four Design Patterns book where Model, and View have been generalized to Subject and Observer respectively.

In Smalltalk the ability to manage a list of dependents and notify them on changes is something that every object can do, but very few objects actually use this capability. In order to avoid having an instance variable in every Smalltalk object to reference a dependents collection which is almost always empty, the default implementation actually keeps a global hash which maps objects with dependents to their dependent collection.

The problem with this default implementation is that once an object gains a dependent, the object and it’s dependent objects are permanently reachable, and therefore ineligible for garbage collection, unless the dependency is explicitly removed. As a result of this, the classes of most objects which actually have dependents reimplement the default methods to refer to the dependents collection via an instance value in the object with dependents. Squeak, for example provides a subclass of object called Model which provides such a GC friendly implementation.

Which brings me to the implementation of the observer pattern in Ruby. In his discussion of this pattern in his book, Russ Olsen provides a module which can be mixed into an object to allow it to have dependents:

module Subject
  def initialize
    @observers = []
  end

  def add_observer(&observer)
    @observers << observer
  end

  def delete_observer(observer)
    @observers.delete(observer)
  end

  def notify_observers
    @observers.each do |observer|
      observer.call(self)
    end
  end  
end

This is a nice Ruby spin on the pattern, in that the Observers can be blocks, or any other object which responds to a call method which takes the Subject as its argument.

Shortly before seeing the book, as a result of that GC thread, I’d written my own variation on this, which let’s any object be a subject, by opening up the Object class:

class Object
    def add_observer(&observer)
      (@observers ||= []) << observer
    end

    def delete_observer(observer)
      observers.delete(observer)
    end

    def notify_observers
      observers.each do |observer|
        observer.call(self)
      end
    end

    private
    def observers
      @observers || []
    end 
end

Because of the fact that Ruby only adds instance variables on the fly as needed, we get the benefit of universal support for objects to be Subjects without requiring an observers instance variable for those objects which don’t. The only cost is the potential namespace collision for the four method names.

Another Use of Dynamic Instance Variables

Recently I wrote an article for InfoQ about James Golick’s resource_controller plugin for Rails which allows you to write Rails controllers for RESTful resources which can automatically adapt for use in different resource nesting contexts. This plugin makes good use of the dynamic nature of Ruby instance variables, automatically defining different instance variables in the controller to correspond to the end resource and each of its parent resources.

Whew!

This has turned out to be a rather long article, which I’ve been meaning to write for some time. I hope that someone finds it useful, or at least interesting.

On Variables, Values, and Objects

Rick DeNatale — Wed, 13 Sep 2006 15:47:00 -0400

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.

Ruby Variables Don’t Have (Permanent) Classes

In one recent thread, someone suggested adding a method to the “class of a variable.” The problem with this idea, is that a variable doesn’t really have a class. For example, consider thiscode:

require 'matrix'
   a = 5
   a = a * 1.0
   a = a * Matrix.identity(3)

Here the variable a refers to a sequence of objects, each with a different class. First a Fixnum, then a Float, then a Matrix. While Fixnum, and Float inherit from Numeric, Matrix doesn’t but it can form a duck-type with Numeric in many uses.

This also illustrates that “all variables are the same size.” In a language like C, a variable holding an integer, will probably have a diffferent size as one holding a double (which is what Ruby defines as the representation of a float), and one which holds a 3×3 matrix of doubles certainly will be bigger than one holding a scalar double.

Ruby Variables Hold Object References, not Object State

The magic which allows this is the fact that in Ruby, as in Smalltalk, a variable doesn’t hold the “bag-of-bits” which represents a particular data-structure. Instead it contains a reference to an object which holds the “bag-of-bits.” The actual structure of that “bag-of-bits” is of no concern to, and is hidden from the variable and it’s users.

This encapsulation barrier is key to what makes a language truly “object-oriented,” at least the way I use the term.

The “bag-of-bits” which represents a particular object is visible to the methods of that object’s class, at least in an abstract way. Some details are even hidden to those methods at the Ruby source code level, and are tied up in the language implementation, hand written extensions to Ruby usually do need to deal with those details.

In Smalltalk, the pseudo-variable self is actually strongly typed in the C-sense since instances of Smalltalk classes have a fixed structure, and self in a method is guaranteed to refer to an instance of the class owning the method or one of it’s subclasses, and instance variables are found in known slots within the object.

In Ruby it’s a little different because Ruby instance variables are created dynamically and accessed via a hash table within the object, at least in the 1.8.x implementation.

As a first approximation, we can initially think of variables as holding pointers to objects, but I’ll expose this for the pedagogical lie that it is, a little later in this article.

Mutability, and Aliasing

Here’s one of those stumbling blocks for those who expect variables in a uniformly object-oriented language to work like they do in a language like C or Fortran:

 1: a = [1, 2, 3]
 2: b = [1, 2, 3]
 3: c = a

 4: a[1] = 0

 5: p a #=> [1, 0, 3]
 6: p b #=> [1, 2, 3]
 7: p c #=> [1, 0, 3]

Everything looks pretty normal up ot line 7. We never did anything with c after we assigned it a value, but it doesn’t seem to have held it’s value.

Or has it?

Well, it actually has, since it’s value is a reference to an object, and that object is the same one referenced by a.

Line 4 might look like an assignment to the variable a, but it’s really a method call to the array which a happens to be referencing at the time. And that method (called []=) changes, or mutates that array. That change will be visible through the variables a, c and any others that reference that particular array. Multiple references to the same object are called aliases to that object. They might be named variables, or referenced which are inside another object:

 8: d = [[1, 2, 3], [4, 5, 6]]
 9: e = d
10: d[1][1] = "Fred"
11: p e #=> [[1, 2, 3], [4, "Fred", 5]]]

While such mutating methods are often very useful, this effect of aliasing is something which the Ruby programmer who uses them needs to keep in mind.

Many built-in Ruby classes have both mutating, and non-mutating versions of methods, for example Array#compact returns a new array which is a copy of the receiver with nil elements removed, leaving the original array intact, while Array#compact! mutates the receiver and removes the nil’s in-place.

As with compact and ocmpact!, it’s standard practice to give such mutating methods a name with a trailing ‘!’ which serves as a warning that they mutate the receiver. It’s a warning to the wise.

That Little White/Pedagogical Lie, or Variables and Object Identity

I said above that thinking that variables hold pointers to objects was a first approximation to reality. The fact is they really don’t

12: a1 = [1, 2, 3]
13: a2 = [1, 2, 3]
14: p a1.object_id #=> -605450882
15: p a2.object_id #=> -605225658

The object_id method returns a number which is unique in the sense that no two active objects will ever have the same object_id, and a given object will always have the same object_id. In the Ruby 1.8.x implementation, object_id actually just gives the bits of the value used to reference the object in the guise of a Fixnum.

So we see here that a1 and a2 are diffferent objects. Let’s try a few more objects:

14: i1 = 1
15: i2 = 1
16: p i1.object_id #=> 3
17: p i2.object_id #=> 3
18: sym1 = :sym
19: sym2 = :sym
20: p sym1.object_id #=> 4090126
21: p sym2.object_id #=> 4090126

Here’s another surprise. Before when we created two different arrays, we ended up with two different objects. But even though we never assigned i2 to i1, or sym2 to sym1, the ‘two’ 1s have the same object_id, and the ‘two’ symbols named :sym share an object_id, what’s that about?

Certain classes ensure that if ‘two’ of their instances are equal they are the same object. We can see that Fixnum, and Symbol do this, others are NilClass, TrueClass, and FalseClass. For symbols, this conflation of value and identity is part of their definition, for the others, it’s probably not strictly necessary, but it makes some common operations like testing for equality, and in the case of Fixnums arithmetic operations, much faster.

What’s really held in variables is a value which can either be used to recognize that the object is one of these special objects, or that can be mapped efficiently to the real address of the object. The details are implementation-specific, and not really germane to the current topic, so I won’t go into them in this article.

Immutable Objects

It’s often advisable to design classes without mutating methods. For example, Fixnum has a method [] which returns the nth bit of the representation of the number where bit 0 is the least significant bit. Suppose that it also had a method []=, which set the value of the cooresponding bit:

#Hypothetical code - with a tribute to Jimi Hendrix
h1: a = 6
h2: b = 6
h3: a[0] = 1; a[1] = 0; a[2] = 0; a[3] = 1
h3: p a #=> 9
h4: p b #=> 9

Since all 6’s are the same object, then if Fixnum had mutating methods, we could make all 6’s turn out to be 9. While Jimi might not mind, my program might not like it.

And it would cause head-scratching debugging sessions. Thirty-two years ago, I found myself in just such a situation. Fortran II had a bug in the language specification which allowed the value of integer literals to be changed when you passed a literal as an argument to a subroutine which assigned to that argument. I spent over a day trying to figure out why my program didn’t work.

For this reason, to quote Martha Stewart, it’s a good thing that the Ruby numeric classes don’t have mutating methods. Even though Bignums and Floats don’t conflate value with identity, it would probably be even more mystifying to find that some instance of 1.5 changed to 1.45 when other’s didn’t. To me it seems far better to head off that particular ‘feature’ at the pass.

Another reason for this choice of immutability is taken from functional programming. Although Ruby is not really an FP language, it takes many concepts from that paradigm. In FP, functions with side-effects are disallowed, and mutation is certainly a side-effect. Taking FP to the limit makes doing things which require side-effects, like I/O, take special tricks. Ruby allows side-effects, and doesn’t require an FP approach, but like other features like regular expressions, understanding functional approaches is a useful tool in the Ruby programmer’s bag.

Immutability at the Instance Level

Ruby Object’s have a freeze method which makes a particular instance immutable:

F1: a1 = [1, 2, 3]
F2: a2 = a1
F3: a1.freeze
F4: a1[1] = "Fred" #=> TypeError: can't modify frozen array
F5: a2[1] = "Fred" #=> TypeError: can't modify frozen array

Beware, though, that this only freezes the object itself and not it’s sub-objects, or referenced objects:

F6: a3 = [[1, 2, 3], [4, 5, 6]]
F7: a3.freeze
F8: a3[0][1] = "Fred"
F9: p a3 #=> [[1, "Fred", 3], [4, 5, 6]]

Matrix and Mutability

Following the pattern established by Numerics, the designer of the Matrix class, who, according to the comments in the source code, ported it from Smalltalk, made Matrix instances immutable.

This upsets some who prefer to think of a Matrix as a 2-dimensional array rather than a mathematical construct which acts much like a numeric in linear algebra.

If you want to view matrices that way you’ve got a few choices:

Swim-against the current: Monkey-patch Matrix to add mutating methods.

Swim with the current: Use the Matrix#to_a and Matrix[] to get a mutable array and then create a new Matrix from it:

M1: m1 = Matrix.identity(3)
M2: p.m1 #=> Matrix[[1, 0, 0], [0, 1, 0], [0, 0, 1]]
M3: a1 = m1.to_a
M4  a1[1][1] = 3
M4  m1 = Matrix[a1]
M5: p m1 #=> Matrix[[[1, 0, 0], [0, 3, 0], [0, 0, 1]]]

Find a new stream: look at other sources of a mutable 2-dimensional array, for example

The choice, gentle reader, is yours. I hope that my efforts help you make it a more informed choice.