Yeah—this technique is simple, but really underappreciated.

However, if you’re using it to optimize @country ||= ..., it’s worth noting that the following technique creates a considerably faster accessor:

def country
  class << self ; attr_reader :country end
  @country = `geoiplookup #{@ip}`.
    chomp.gsub(/^GeoIP Country Edition: /,"")
end

A benchmark of 5,000,000 reads comes out like:

As you can see, attr_reader wins by quite a bit.

class Fixnum def + (a) case rand 4 when 0 def + (b); self+b end when 1 def + (b); self*b end when 2 def + (b); self-b end when 3 def + (b); self/b end end end end

class Fixnum
  def + (a)
    case rand 4
      when 0
        def + (b); self+b end
      when 1
        def + (b); self*b end
      when 2
        def + (b); self-b end
      when 3
        def + (b); self/b end
    end
  end
end

Hmm… is this better than the traditional form of memoization? Or does it have adverse effects by comparison?

Also, I’m still looking for a way to task dependencies with parameters just by calling them like methods at the beginning of the task def—I wonder if this would work?

trans: it can be bad with inheritance—e.g. if somebody derives from Hit and overrides Hit#country, you will clobber that. Otherwise, singleton-methods-for-memoization is very win.

It’s worth nothing that self-replacing methods aren’t only for destruction, memoization, and messing with people who are fond of Fixnum#+ (I think that is most of us)—you can use them to maintain state. For example, here’s a state machine which recognizes a sequence like a(bc)*(a|c):

class Recognizer
  def initialize ; _start end

  def reset ; _start end

private
  def _start
    def self.match( k )
      case k
      when :a: _S0
      else _fail
      end
    end
    def self.finish
      _fail
    end
  end

  def _S0
    def self.match( k )
      case k
      when :b: _S1
      else _S2 ; match( k )
      end
    end
  end

  def _S1
    def self.match( k )
      case k
      when :c: _S0
      else _fail
      end
    end
  end

  def _S2
    def self.match( k )
      case k
      when :a: _end
      when :c: _end
      else _fail
      end
    end
  end

  def _end
    def self.match( k ) ; _fail ; end
    def self.finish ; end
  end

  def _fail
    def self.match( k ) ; _fail ; end
    def self.finish ; _fail ; end
    raise "match failed" 
  end
end

r = Recognizer.new
# will match
[ :a, :b, :c, :b, :c, :c ].each do |k|
  r.match k
end
r.finish

r.reset
# will fail
[ :a, :b, :b, :c, :a ].each do |k|
  r.match k
end
r.finish

This is an objectless embodiment of the State pattern, in much the same way that Ruby iterators are an objectless embodiment of the Visitor pattern.

MenTaLguY: Thanks for the benchmark. That’s really nice to know.

Since when have we been able to have def...end directly inside def...end, without a class definition nested between? I’ve not attempted this for a while but when I last tried it, I got a error. I concluded there was a reason for this by design, and left it there. Now, even with 1.8.2 I can. So, do we need define_method any more?

MenTaLguY: object-less State pattern: Nice!

I feel pulled two ways: this is powerful and the mechanism is clear, but it is self-modifying code, which one is taught to avoid. Or do I need to unlearn that? After all, goto is OK in the right circumstances…

hgs: you need to unlearn all that. Otherwise you’ll never do any metaprogramming. That rule against self-modifying code was for a static world. We now are boldly entering a new dynamic world and _why is leading the way! Onward to the glorious, dynamic future!

...OK, just don’t get too carried away with it. Use judiciously. Proceed with caution but tread with confidence. Remember: self-modifying code can smell fear – never let it know you’re afraid and you’ll be fine. A bit like lion taming in that regard.

Yes, good point about parallels with metaprogramming. And fear is the mind-killer, of course :-)

You’re welcome! However, I got curious how memoized reads compare to the one-time setup overhead. This is what I found (times are normalized):

This means that it takes a few calls to “break even”, and a few more before one of the “faster” techniques finally wins:

I think there’s probably a lesson here…

Do you really need the self. here? Wouldn’t

def runme def runme; end end

Work just the same?

hgs: you’ve always (as far as I know) been able to do a def obj.meth outside a class or module, just never a regular def. The rationale: the receiver of the method definition is explicit when you’re defining a singleton method on an object, but if you’re outside a class or module and say def meth, where does it go?

self.class isn’t always a desirable answer for that, nor is “the class/module on which the enclosing method was defined”...

.: it’s not allowed syntax. If it were, I’m not sure people could agree on what it should mean.

MenTaLguY: Welp, I guess the lesson is:

 def country
   if @past == 12
     def self.country
       @past += 1
       @country
     end
   end
   @country ||= (@past = 0) && `geoip...`
   @past += 1
   @country
 end

pHiL: I think the thing to ask is always “does doing it this way make the code clearer?”

.: it’s not allowed syntax. If it were, I’m not sure people could agree on what it should mean.

His syntax works for me without warning or error on Ruby 1.8.4.

class Doggie
    def praise
        def praise; puts "Bad boy"; end
        puts "Good boy" 
    end
end

h = Doggie.new
3.times do h.praise end

r = Doggie.new
3.times do r.praise end

With one difference: def praise overwrites the method. That is, the output is one “Good boy” and five “Bad boy” instead of two “Good boy” and four “Bad boy,” which is what def self.praise does.

Fun.

More proof cats are for the wins and dogs are not.

why: Dude, no, it’s got to be something like this:

def country
  start = Time.now
  deffed = Thread.new {
    def self.country ; @country end
    self.country 
  }.value
  deffed_time = Time.now - start
  start = Time.now
  regular = Thread.new {
    @country ||= `geoip...`
  }.value
  regular_time = Time.now - start
  [ [ regular, regular_time ],
    [ deffed, deffed_time ] ].sort \
  do |(r0, t0), (r1, t1)|
    t0 <=> t1
  end.first.first
end

shadytrees: Wow, okay, see—I am very good at coming up with rationalizations for things which are totally wrong.

So, playing with it, the answer to where the method goes appears to be “the lexically innermost enclosing class/module block at the site where the method was defined, or Object if there is no such enclosing block”.

That means you have to be careful with def inside of a def obj.meth versus a def inside a def in class << obj. The former will put the method in the lexically enclosing class, not the singleton class of obj.

Nice timing, I just wrote up an article on the same thing, but alas with much less brevity and wit :(

attr_accessor and friends are faster than real methods because they throw out the scope:

$ parse_tree_show
class X
attr_reader :x
def y; @y; end
end
[[:class,
  :X,
  :Object,
  [:defn, :x, [:ivar, :@x]],
  [:defn, :y, [:scope, [:block, [:args], [:ivar, :@y]]]]]]

How does one look up old ruby blog articles on whytheluckystiff as per some old thoughts…?

nonni: Googling with the expression site:whytheluckystiff.net along with your other keywords will probably help until a better answer appears.