what is motivation for setting klass = self in this section of code

Question

I was looking through some code in discourse and stumbled across this and was wondering why klass = self. As I know they are better ruby developers than I, there must be a good reason.

Why wouldn't they call self.remove_from_cache!(message["key"], false)? Is the block creating a new scope where self refers to the class of MessageBus? Are there other examples of where you would need to create this type of construct in Ruby or is this the main one? If MessageBus.subscribe was an instance of a MessageBus (say m_bus.subscribe) would self refer to m_bus in the block? Does the fact that ensure_class_listener is class method have any bearing on this? Sorry for all the questions but just want to be sure.

thx

https://github.com/discourse/discourse/blob/master/app/models/site_customization.rb#L118

  def self.ensure_cache_listener
    unless @subscribed
      klass = self
      MessageBus.subscribe("/site_customization") do |msg|
        message = msg.data
        # what would self her refer to
        # what would self her refer to
        # would self.remove_from_cache!(message["key"], false) 
        klass.remove_from_cache!(message["key"], false)
      end

      @subscribed = true
    end
  end

EDIT #1

The implementation of MessageBus.subscribe appears to be here: https://github.com/SamSaffron/message_bus/blob/master/lib/message_bus.rb#L217

Answer 1

First of all:

Is the block creating a new scope where self refers to the class of MessageBus?

Nope.

If MessageBus.subscribe was an instance of a MessageBus (say m_bus.subscribe) would self refer to m_bus in the block?

Nope.

Does the fact that ensure_class_listener is class method have any bearing on this?

Nope.

---

Let's start with a simple example:

def test_self
  p self

  2.times do |n|
    p self
  end
end

test_self

prints out

main
main
main

As you can see self refers to the same object, the top level main object.

Now, to the interesting part:

class Foo
  def test_self(&block)
    block.call
  end
end

p self
Foo.new.test_self do
  p self
end

gives

main
main

Not too surprising, we are passing a block along and calling from within our object. But if we try with this:

class Foo
  def test_self(&block)
    instance_eval(&block)
  end
end

p self

Foo.new.test_self do
  p self
end

gives

main
#<Foo:0x007f908a97c698>

WUT???

Ruby's instance_eval can take a block and run it using the current object as self: in this way the same block of code changed its meaning.

---

Therefore, my assumption is that MessageBus is doing something equivalent: for this reason, we can't pass self from within the block because it will change its meaning when being instance_evaled

---

EDIT!!!

I've looked at the message bus implementation and there isn't a good reason why we should do klass = self.

Look here, we take the block and save it in an internal data structure:

def subscribe_impl(channel, site_id, &blk)
  # ...
  @subscriptions[site_id][channel] << blk
  ensure_subscriber_thread
  blk
end

Now let's look at what ensure_subscriber_thread does:

multi_each(globals,locals, global_globals, local_globals) do |c|
  # ...
  c.call msg
  # ...
end

So it just calls the block, no instance_eval or instance_exec at all!

---

My new Hypothesis

Discourse is an application with a lof of Javascript; it is a very common pattern in Javascript to do this:

var self = this;
$("ul.posts").click(function() {
  // here this does refer to the DOM element
  self.doStuff();
})

So I guess it just leaked into ruby aswell, note that it doesn't do anything wrong, it's just useless! :D

Answer 2

I don't know Discourse's code base well enough to say for sure, but my guess would be that MessageBus.subscribe uses instance_exec with the block passed to it to enable some sort of DSL within the block. If that's the case, then self would point to the object containing the DSL's methods within that block.

Setting klass to self outside the block and using that inside the block ensures that remove_from_cache! is actually getting called on the same self that's referred to outside the subscribe block.

Answer 3

Yes, it could very well be that the blocked passed to MessageBus.subscribe is being eval'd in a different context where self is not equal to the outer scope's self. Under the hood this can be implemented with instance_exec: http://ruby-doc.org/core-1.9.3/BasicObject.html#method-i-instance_exec

It can be helpful in writing clean DSLs (for config objects for example):

class SiteConfig
  class << self
    def setup(&block)
      instance_exec &block
    end

    def domain(str = nil)
      @domain ||= str
    end
  end
end

SiteConfig.setup do
  domain 'test.com'
end
SiteConfig.domain # => 'test.com'

A contrived example, yes but, hopefully it illustrates the point.

Answer 4

+1 to @JuLiu's answer for the lengthy explanation, but I suspect that this particular case is one where defining klass is not needed.

Using git blame sadly yields no further (it was part of the original commit).

A cursory look at the source code yields no instance_eval/exec calls, so the block even passes the message as an argument for good measure.

And the code would work without the klass = self part.

My best guess is this one: the rest of the code base indicates use of the same pattern in various js functions: var self = this, and it's something nobody bothered to clean up. In other words, mindless consistency across the code base.

The only way to be sure, btw, would be to actually edit or vendor the gem and add a p self call or something to that order within the block, and see what it outputs. If there's a hidden instance_eval call underneath, you'll then see who is self.