Dynamically defined classes incorrectly sharing data - bug, or coding error?

Question

I've been trying to set up a system whereby I can generate a series of similar Ruby classes, distinguished by an integer parameter, which I save into a class variable of the relevant class - something akin to C++ templates.

However, referencing (hence, creating) a new version of the templated class overwrites the saved parameters in the previous versions, and I can't work out why.

Here's a minimal example

class Object
  def self.const_missing(name)
    if name =~ /^Templ(\d+)$/
      return make_templ $1.to_i
    else
      raise NameError.new("uninitialised constant #{name}")
    end
  end

private
  def make_templ(base)
    # Make sure we don't define twice
    if Object.const_defined? "Templ#{base}"
      return Object.const_get "Templ#{base}"
    else
      # Define a stub class
      Object.class_eval "class Templ#{base}; end"

      # Open the class and define the actual things we need.
      Object.const_get("Templ#{base}").class_exec(base) do |in_base|        
        @@base = in_base

        def initialize
          puts "Inited with base == #{@@base}"
        end
      end

      Object.const_get("Templ#{base}")
    end
  end
end

irb(main):002:0> Templ1.new
Inited with base == 1
=> #<Templ1:0x26c11c8>
irb(main):003:0> Templ2.new
Inited with base == 2
=> #<Templ2:0x20a8370>
irb(main):004:0> Templ1.new
Inited with base == 2
=> #<Templ1:0x261d908>

Have I found a bug in my Ruby (ruby 1.9.2p290 (2011-07-09) [i386-mingw32]), or have I simply coded something wrong?

Answer 1

Because you first syntactically reference @@base in the context of class Object, it's a class variable of Object and all the TemplX subclasses of object refer to the superclass's class var. You can change your code to use Module#class_variable_set and class_variable_get to avoid the binding in the superclass.

A few other issues with your code: I note you didn't make make_templ a class method peer of self.const_missing, though it dispatched successfully because Object is an ancestor of Class. It's best to avoid all forms of eval(string) when other methods exist. You shouldn't raise NameError if you don't handle the const_missing, but rather dispatch to super as someone else may be in the chain and want to do something to resolve the constant.

class Object
  def self.const_missing(name)
    if name =~ /^Templ(\d+)$/
      return make_templ $1.to_i
    end
    super
  end

private
  def self.make_templ(base)
    klass_name = "Templ#{base}"
    unless const_defined? klass_name
      klass = Class.new(Object) do
        class_variable_set :@@base, base
        def initialize
          puts "Inited with base == #{self.class.class_variable_get(:@@base)}"
        end
      end
      const_set klass_name, klass    
    end

    const_get klass_name
  end
end

Class variables have interesting and often undesirable information mixing properties through inheritance. You've hit one of the gotchas. I don't know what other properties you need around @@base, but it looks likely that you'll get better isolation and less suprising results using a class instance variable instead. For more explanation: Fowler, RailsTips