Repost: singleton methods vs. class instance vars

[Peter Lacey]

Hi,

Please excuse me if this message was already delivered. I'm sending
it again as I suspect something went wrong with my original post
because it didn't get cross-posted to comp.lang.ruby and there were
no replies from a typically very helpful audience.

Pete

Original message:

I'm liberally helping myself to some of the ActiveRecord code. In
this code there are a handful of class methods that dynamically
create singleton methods to override the base methods. A simplified
version follows:

class SingletonBase
class << self
def table_name
reset_table_name
end

def reset_table_name
puts "reset_table_name called"
name = self.name
sing = class << self; self; end
sing.class_eval "def table_name; #{name.inspect}; end"
name
end
end
end

(I hope that simplifying the code didn't remove anything of importance.)

In this code the first time SingletonBase#table_name is called it
calls SingletonBase#reset_table_name. reset_table_name in turn
creates a singleton class and adds a method that overrides table_name
to return what was just calculated.

Fine.

But my question is, is there any reason to prefer this method over
using class instance variables, which seem a little clearer and
simpler? Ala:

class InstanceBase
class << self
def table_name
@table_name || reset_table_name
end

def reset_table_name
puts "reset_table_name called"
@table_name = self.name
end
end
end

If both of these classes are exercised as follows, the results are
comparable:

class Sub_SingletonBase1 < SingletonBase
p table_name
p table_name
end

class Sub_SingletonBase2 < SingletonBase
p table_name
p table_name
end

class Sub_InstanceBase1 < InstanceBase
p table_name
p table_name
end

class Sub_InstanceBase2 < InstanceBase
p table_name
p table_name
end

Output:

reset_table_name called
"Sub_SingletonBase1"
"Sub_SingletonBase1"

reset_table_name called
"Sub_SingletonBase2"
"Sub_SingletonBase2"

reset_table_name called
"Sub_InstanceBase1"
"Sub_InstanceBase1"

reset_table_name called
"Sub_InstanceBase2"
"Sub_InstanceBase2"

Note that there are class methods in ActiveRecord that _do_ use class
instance variables, but not all. In particular for setting/getting
table_name, primary_key, inheritance_column, and sequence_name,
basically everything that can be set by the user. So, what benefit
is derived from using virtual/meta/singleton/eigen-classes over class
instance variables?

Regards,
Pete

 

[ako...]

hello,

apparently ruby as most other languages has more than one way to
express the same thing. i myself see no advantage of the code in active
record that you posted and your code. except for the active record code
is faster than yours because it does not check any variables at all
when evaluating the table_name method.

konstantin

 

[Phil Tomson]

hello,

apparently ruby as most other languages has more than one way to
express the same thing. i myself see no advantage of the code in active
record that you posted and your code. except for the active record code
is faster than yours because it does not check any variables at all
when evaluating the table_name method.

I'm not so sure it's faster; it uses a class_eval.

Phil

 

[Peter Lacey]

I'm not so sure it's faster; it uses a class_eval.

There's a comment in the actual active record code that notes that
class_eval is used over define_method to get around a memory leak in
fcgi.

But to Ako's point, it seems to me that there has to be some
important difference between the singleton approach and the class
instance var approach for several reasons:

1. DHH and the other active record coders and reviewers know what
they're doing, and I suspect this seemingly convoluted code wouldn't
have survived for very long if it was simply "another way of doing it."

2. I'm very new to Ruby, and I don't know what I'm doing.

3. The active record code _does_ use class instance vars in other
places, so this looks very intentional.

Any other thoughts?

Regards,
Pete

 

[Ross Bamford]

There's a comment in the actual active record code that notes that
class_eval is used over define_method to get around a memory leak in
fcgi.

But to Ako's point, it seems to me that there has to be some important
difference between the singleton approach and the class instance var
approach for several reasons:

1. DHH and the other active record coders and reviewers know what
they're doing, and I suspect this seemingly convoluted code wouldn't
have survived for very long if it was simply "another way of doing it."

2. I'm very new to Ruby, and I don't know what I'm doing.

3. The active record code _does_ use class instance vars in other
places, so this looks very intentional.

Seems to me the technique is about one-time creation of attribute
accessors that, instead of looking like:

def name
"name"
end

Which, when called multiple times, may be faster than equivalent instance
variable lookups. My *guess* is that this is probably a bit quicker with
symbols and maybe strings (which is what this seems to be using - notice
the 'inspect' too) than going for an instance var.

?

 

[Ross Bamford]

Ahem, sorry.

Seems to me the technique is about one-time creation of attribute
accessors that, instead of looking like:

def name
@name
end

look like this:

 

[Peter Lacey]

Maybe, but that's a lot of optimization for a little problem. These
four active record methods (table_name, primary_key, etc.) can't be
called so often that it becomes necessary to avoid the cost of
dereferencing a variable.

There's an article by _why the lucky stiff_ (http://
whytheluckystiff.net/articles/seeingMetaclassesClearly.html) that
gets tantalizingly close to answering this question, but not close
enough. At least not for me. _why, are you lurking? Any input?

I dunno, maybe I'm looking for something that's not there, but I'd
love to keep the discussion going for a bit, if I may.

Pete

 

[Phil Tomson]

ooops, I see that the class_eval is only called once so maybe it's correct
that that version is faster overall.

There's a comment in the actual active record code that notes that
class_eval is used over define_method to get around a memory leak in
fcgi.

But to Ako's point, it seems to me that there has to be some
important difference between the singleton approach and the class
instance var approach for several reasons:

1. DHH and the other active record coders and reviewers know what
they're doing, and I suspect this seemingly convoluted code wouldn't
have survived for very long if it was simply "another way of doing it."

3. The active record code _does_ use class instance vars in other
places, so this looks very intentional.

I wouldn't be so sure... I suspect that DHH's (and the other Rails
contributors) Ruby skills and understanding have increased over time
and maybe if they were writing the code from scratch now they would use the
class instance variable method as opposed to the class_eval method. I know
that I've got a lot of Ruby code out there that I wrote early on that I would
write very differently now... Sometimes code survives because it works.

2. I'm very new to Ruby, and I don't know what I'm doing.

3. The active record code _does_ use class instance vars in other
places, so this looks very intentional.

Like I said above, it's possible that the class instance var meme came later
in the development history of Rails and that they started using it after it
became known to them. Only DHH can say for sure ;-)


Phil

 

[Peter Lacey]

Final post in this thread. It seems that the consensus is that these
two approaches are equal in terms of their results. Knowing that, it
would appear that I _did_ oversimplify my original post. For the
sake of the question I had distilled the active record code to this:

class SingletonBase
class << self
def table_name
reset_table_name
end

def reset_table_name
puts "reset_table_name called"
name = self.name
sing = class << self; self; end
sing.class_eval "def table_name; #{name.inspect}; end"
name
end
end
end

However, the actual code is more (but not exactly, in the interest of
brevity) like this:

class Base
class << self
def table_name
reset_table_name
end

def reset_table_name
name = self.name
set_table_name name
name
end

def set_table_name( value=nil, &block )
sing = class << self; self; end
if value
sing.class_eval "def #{name}; #{value.to_s.inspect}; end"
else
sing.send :define_method, name, &block
end
end
end
end

It would appear, then, that the singleton class is created solely for
handling the optional block parameter, and not, as I originally
suspected, for some more global reason.

Sorry for the wild goose chase and thank you for your insight.

Pete