inherited - any class posted by Dave Thomas @ Fri, 21 Nov 2008 14:28:20 -0000

Dave Thomas — Fri, 21 Nov 2008 14:28:20 -0000

Mike:

New classes are subclasses of Object, not Class:


class Object
    def self.inherited(by)
        p "inherited by #{by}" 
        super
    end
end

class Dave
end

class Mike
end

inherited - any class posted by Michael Stramba @ Fri, 21 Nov 2008 03:14:43 -0000

Michael Stramba — Fri, 21 Nov 2008 03:14:43 -0000

Dave,

Is it possible to use ‘inherited’ to monitor any/every class ?

I.e. instead of the hard coded “Parent” class in your example, it could monitor any class name, or accept a list of class names to monitor.

(Like ‘def included’ example using class Module, that monitors any module/class interaction).

I tried :


class Class
  def self.inherited(by)
    puts "#{self} was inherited by #{by}" 
  end
end

class Child < Class
end

class OtherChild < Class
end

But get “can’t make subclass of Class” (TypeError)

Mike

My heartfelt thanks to Dave posted by Todd W Crone @ Tue, 28 Oct 2008 14:13:52 -0000

Todd W Crone — Tue, 28 Oct 2008 14:13:52 -0000

Add another gold star to Dave’s screencasts. I am going through the screencasts a second time now and I am still learning SOOOOO much. I have been a failed Ruby programmer trying to come over from Java several times. After learning some Groovy I got going on these screencasts and now I can honestly say I am FINALLY on my way to enlightenment! God bless you guys at Pragmatic Bookshelf for all your guidance and passion for your craft. I am sure your efforts are worth far more than $5/episode teaching us novices how to move closer to becoming experts.

Call old mehod added posted by Jon Stenqvist @ Sun, 19 Oct 2008 09:57:23 -0000

Jon Stenqvist — Sun, 19 Oct 2008 09:57:23 -0000

I want to call the old method added it here is one.


  def self.included(klass)
    define_callbacks_for_update_from_xml(klass)
    if klass.instance_methods.include?('update_from_xml')
      wrap_update_from_xml_method(klass)
    else
      (class << klass; self; end).class_eval do
        old_method_added = instance_method(:method_added)
        define_method(:method_added) do |name|
          old_method_added.bind(self).call(name) if old_method_added
          return unless name == :update_from_xml
          XmlUpdatable.suppress_method_added_hook do
            XmlUpdatable.wrap_update_from_xml_method(self)
          end
        end
      end
    end
  end

But I'm getting this error

/Users/jcodeon/code/equipe/lib/xml_updatable.rb:13:in `bind': singleton method bound for a different object (TypeError) from /Users/jon/code/equipe/lib/xml_updatable.rb:13:in `method_added' from /Users/jon/code/equipe/vendor/rails/activerecord/lib/active_record/associations.rb:1235:in `define_method' from /Users/jon/code/equipe/vendor/rails/activerecord/lib/active_record/associations.rb:1235:in `association_accessor_methods' from /Users/jon/code/equipe/vendor/rails/activerecord/lib/active_record/associations.rb:1005:in `belongs_to' from /Users/jon/code/equipe/app/models/class_section.rb:26 from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:27:in `gem_original_require' from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:27:in `require' from /Users/jon/code/equipe/vendor/rails/activesupport/lib/active_support/dependencies.rb:148:in `require' ... 53 levels... from /Users/jon/Library/Application Support/TextMate/Bundles/RSpec.tmbundle/Support/lib/spec/../spec/mate/runner.rb:31:in `chdir' from /Users/jon/Library/Application Support/TextMate/Bundles/RSpec.tmbundle/Support/lib/spec/../spec/mate/runner.rb:31:in `run' from /Users/jon/Library/Application Support/TextMate/Bundles/RSpec.tmbundle/Support/lib/spec/../spec/mate/runner.rb:14:in `run_file' from /tmp/textmate-command-8094.rb:3

My heartfelt thanks to Dave posted by Nate Kidwell @ Sun, 21 Sep 2008 16:19:04 -0000

Nate Kidwell — Sun, 21 Sep 2008 16:19:04 -0000

Want to echo everyone’s sentiments here. The only one that I’ve had any confusion with was #7, and that was due to the deep magic involved rather than Dave Thomas’ presentation itself.

A really great series – he’s like a civilized version of WhyTheLuckyStiff!

Episode 6 posted by Jon Stenqvist @ Tue, 09 Sep 2008 18:23:39 -0000

Jon Stenqvist — Tue, 09 Sep 2008 18:23:39 -0000

Does also const_set ignore instance/class_eval?


class Application
end

Application.instance_eval do
  const_set(:TEST_CONST,"JON")
end

Application.class_eval do
  const_set(:TEST_CONST,"JON")
end

Episode 6 posted by Jon Stenqvist @ Mon, 08 Sep 2008 17:51:17 -0000

Jon Stenqvist — Mon, 08 Sep 2008 17:51:17 -0000

As a novice on this I want rules ;) After getting the metaclass, the preferred would be to use class_eval because I want to add a instance method to the metaclass?

Episode 6 posted by Dave Thomas @ Mon, 08 Sep 2008 03:35:25 -0000

Dave Thomas — Mon, 08 Sep 2008 03:35:25 -0000

Jon:

define_method ignores class_ or instance_eval and always defines an instance method.

Dave

Episode 6 posted by Jon Stenqvist @ Sun, 07 Sep 2008 20:46:03 -0000

Jon Stenqvist — Sun, 07 Sep 2008 20:46:03 -0000

Hi,

Thanks for great screencasts.

After getting the “metaclass” class << self; self; end. I can’t find any difference between in using instance_eval and class_eval. I get the feeling that the right method for the job would be instance_eval because it that will create instance methods on the metaclass, and as you told on the screencast there arn’t really any class_methods.

Are there a difference between this two snippets? instance_eval/class_eval.

class Dave
  # def self.const_missing(name)
  #   puts "Missing #{name} in Dave" 
  #   super
  # end
  ghost = class << self; self; end
  ghost.class_eval do
    original_const_missing = instance_method(:const_missing)
    define_method(:const_missing) do |name|
      puts "Missing #{name} in Dave" 
      original_const_missing.bind(self).call(name)
    end
  end
end
Dave::Fred

class Dave
  ghost = class << self; self; end
  ghost.*instance_eval* do
    original_const_missing = instance_method(:const_missing)
    define_method(:const_missing) do |name|
      puts "Missing #{name} in Dave" 
      original_const_missing.bind(self).call(name)
    end
  end
end

An idea for a future installment posted by Ira Davis @ Wed, 03 Sep 2008 21:20:04 -0000

Ira Davis — Wed, 03 Sep 2008 21:20:04 -0000

Do you suppose you could cover the metadata for an object? That is if Ruby exposes this. I’ve really enjoyed the series and I think it has helped my understanding of object orientation in general and certainly helped my understanding or Ruby.

A bit off-topic posted by Dave Thomas @ Tue, 05 Aug 2008 12:55:56 -0000

Dave Thomas — Tue, 05 Aug 2008 12:55:56 -0000

Mathijs:

To be fair, I didn’t say I don’t do unit testing when metaprogramming. I just said I wasn’t doing it in the screencast—after all, it’s already over 50 minutes, and Mike Clark gave me a 30 minute target…

Remember that metaprogramming is orthogonal to your final code. When you write tests, you write tests for the metaprogramming implementation separately from the tests you write for your use of that metaprogramming. And, because they are unit tests, it’s OK to know about the implementation.

Dave

A bit off-topic posted by Mathijs Kwik @ Tue, 05 Aug 2008 07:00:18 -0000

Mathijs Kwik — Tue, 05 Aug 2008 07:00:18 -0000

Dave, in episode 7, you mention you should do unit testing when metaprogramming.
While I try to use unit-testing on most of my normal code, I find it’s harder to unit-test metaprogramming-code.
I always find myself testing the implementation too much instead of the results.
So my tests are bound too much to the code they test, which is a bad thing.

I would be really interested to see you work through episode 7 with unit-testing. Like you said, this breaks up the flow too much for the original screencast, but maybe you can do a separate one on that?
Or could you make your unit-tests (of the final example at least, maybe of some between-steps) available in the code or somewhere else?

This would greatly help me find a nice and safe workflow when metaprogramming.

Thanks,
Mathijs

Not sure how to interpret this? posted by Bharat Ruparel @ Fri, 01 Aug 2008 15:52:04 -0000

Bharat Ruparel — Fri, 01 Aug 2008 15:52:04 -0000

Thanks Jim. I am reading it now. I found the following post by Ola Bini to be particularly helpful. Before David’s screencasts, I could not really understand posts similar to these, I think I do now (at least until the next post asking for help).

http://ola-bini.blogspot.com/2006/09/ruby-singleton-class.html

Regards,

Bharat

Not sure how to interpret this? posted by James Whiteman @ Mon, 28 Jul 2008 16:13:36 -0000

James Whiteman — Mon, 28 Jul 2008 16:13:36 -0000

Bharat,

If you haven’t already checked it out, Why has an excellent article on the above technique:

http://whytheluckystiff.net/articles/seeingMetaclassesClearly.html

In conjunction with Dave’s screencasts, it’s a killer tutorial.

Not sure how to interpret this? posted by Bharat Ruparel @ Sat, 26 Jul 2008 02:07:24 -0000

Bharat Ruparel — Sat, 26 Jul 2008 02:07:24 -0000

And this is on Memoization:

http://ryandaigle.com/articles/2008/7/16/what-s-new-in-edge-rails-memoization

Sounds familiar?

Not sure how to interpret this? posted by Bharat Ruparel @ Tue, 22 Jul 2008 19:41:34 -0000

Bharat Ruparel — Tue, 22 Jul 2008 19:41:34 -0000

Thanks. So essentially it becomes a class method of Object (and inheriting classes) which returns the metaclass ‘class’ (or the ghost class) of type class?

Check this out!

http://github.com/rails/rails/commit/f4f6e57e8c2a446a4a600576f0caf0fb8921ba13

It seems like Rails 2.2 is embracing this stuff. I am pretty sure David already knows this, but is not telling us so as not to scare us off!

Bharat

Not sure how to interpret this? posted by Dave Thomas @ Tue, 22 Jul 2008 03:36:03 -0000

Dave Thomas — Tue, 22 Jul 2008 03:36:03 -0000

We have examples of this in the screencast.


metaclass = class X
  class << self
     self
  end
end

simply returns the ghost class (the value of self in the inner class definition). By defining it in object, the method becomes available in all classes.

Not sure how to interpret this? posted by Bharat Ruparel @ Tue, 22 Jul 2008 01:35:40 -0000

Bharat Ruparel — Tue, 22 Jul 2008 01:35:40 -0000

David,
I am maintaining a Rails App that is using backgroundDrb. It creates a helper file called dbrb_test_helper.rb in the test directory. Amongst other things, it has the following piece of code that I cannot understand:

class Object
 def self.metaclass
  class << self
   self
  end
 end
...
end

So we are adding a “class” method to the Object (class? instance?) named ‘metaclass’. So if I understand your teaching thus far: There is a ghost class created for the object ‘Object’ that has a method metaclass defined in it. So far so good, but what in the world are the following lines of code are for?

class << self
   self
end

I don’t get it. Kindly explain. This is one too many selfs for me.

Bharat

Why cool guys use obj.instance_eval instead of class << obj to define singletons? posted by Dave Thomas @ Sun, 20 Jul 2008 22:47:06 -0000

Dave Thomas — Sun, 20 Jul 2008 22:47:06 -0000

Victor:

I know people use it. I just think they shouldn’t… :)

Why cool guys use obj.instance_eval instead of class << obj to define singletons? posted by Victor Moroz @ Sun, 20 Jul 2008 19:10:44 -0000

Victor Moroz — Sun, 20 Jul 2008 19:10:44 -0000

Actually @@var can be found in many gems, including ActiveSupport, ActiveRecord, haml etc. Of course usage I showed in this post is quite bizzare, but how are you going to share variable between several instances of the same class if you need to access it from instance methods? Well, through class method and class level @var, but it requires additional lines of code. And even if you do this for objects, you can’t do it for classes like it is done in ActiveRecord when all subclasses share the same variable. Maybe it is just wrong use of inheritance, don’t know.

Wow, I just realized that top level works as Object.class_eval block!

Why cool guys use obj.instance_eval instead of class << obj to define singletons? posted by Dave Thomas @ Sun, 20 Jul 2008 16:06:19 -0000

Dave Thomas — Sun, 20 Jul 2008 16:06:19 -0000

As to your first point: that’s one reason I think @@var is unusable in real code. I also suspect that example will no longer work in 1.9. In general, @@var should be avoided.

For the second point: the biggest place the two are different is at the top level of your program…

Why cool guys use obj.instance_eval instead of class << obj to define singletons? posted by Victor Moroz @ Sun, 20 Jul 2008 07:45:20 -0000

Victor Moroz — Sun, 20 Jul 2008 07:45:20 -0000

And even more confusing here


def String.scream
  puts 'wow'
end

String.instance_eval { scream } # wow
String.class_eval { scream } # wow

So when we execute instance_eval and class_eval both blocks are executed in the context of String class (self = String), but ‘def method’ does different things! Well, concept ‘current class’ is reasonable, but how far this concept goes? It means there are two contexts – ‘self’ for calling methods and accessing variables and ‘current class’ for defining methods? Where else these contexts are different?

Why cool guys use obj.instance_eval instead of class << obj to define singletons? posted by Victor Moroz @ Sun, 20 Jul 2008 07:11:58 -0000

Victor Moroz — Sun, 20 Jul 2008 07:11:58 -0000

Or why one should use class << obj if you have instance_eval? After all instance_eval is more convenient and is executed in the ‘obj’ scope (e.g. you can use instance methods), while class << obj is something odd as it is executed in the scope of the ghost class. What can be done in this scope except of defining singletons? Well, just about my favorite @@var – @@var defined inside class << obj becomes common for all classes!


class << "dog" 
  @@var = 1
end

class << Fixnum
  puts @@var     # 1
end

class String
  puts @@var     # 1
end

This means there is not ghost class between singleton ghost class and Class while there is between String and Class for example. Confusing…

Using @@var inside class definition posted by Victor Moroz @ Sun, 20 Jul 2008 03:53:11 -0000

Victor Moroz — Sun, 20 Jul 2008 03:53:11 -0000

Same example with objects


class Cat
  def initialize
    @@has_tail = true
  end
  def has_tail
    @@has_tail
  end
  def has_tail=(tail)
    @@has_tail = tail
  end
end

felix = Cat.new
tom = Cat.new

puts felix.has_tail # true
puts tom.has_tail   # true

def tom.has_tail=(tail)
  @@has_tail = tail
end

tom.has_tail = false

puts felix.has_tail  # true
puts tom.has_tail    # true !!!

def tom.has_tail
  @@has_tail
end

puts tom.has_tail    #false

So it looks like @@var is relative to the place where method is actually defined. If we have ghost class and method is defined in the ghost class as with def tom.has_tail, then @@has_tail will be stored in the ghost class, but if methods defined in the class definition itself, then @@has_tail is stored in the class itself. And Ruby will not check superclass of this ghost class for @@var defined there, that is why previous example failed with ‘uninitialized class variable’ – inheritance does not work here. But previous example (with Cat.has_tail) is much more tricky – actually ‘class’ of class Cat should point to ‘Class’ and @@var should be stored there, but this is not what happens! In this case we would have @@has_tail defined in any class and this is not the case. Does it mean we have actually two ghost classes between Cat and Class?

Using @@var inside class definition posted by Victor Moroz @ Sat, 19 Jul 2008 19:16:02 -0000

Victor Moroz — Sat, 19 Jul 2008 19:16:02 -0000

Hello Dave,

Thanks for the screencast, it is great. Maybe some day you can dig into using @@ variables, especially on class level. It is used in ActiveRecord and is a bit tricky


felix = "felix" 

def felix.has_tail
  @@has_tail
end

def felix.has_tail=(tail)
  @@has_tail = tail
end

felix.has_tail = false
puts felix.has_tail     # false
tom = felix.clone
tom.has_tail = true
puts felix.has_tail     # true

class Cat
  def self.has_tail
    @@has_tail
  end
  def self.has_tail=(tail)
    @@has_tail = tail
  end
end

class Felix < Cat
end

class Tom < Cat
end

Tom.has_tail = true
Felix.has_tail = false
puts Tom.has_tail     # false

But this was the easy part. What I just barely understand


class Cat
  @@has_tail = true
  def self.has_tail
    @@has_tail
  end
end

puts Cat.has_tail  # true

def Cat.has_tail
  @@has_tail
end

puts Cat.has_tail  # uninitialized class variable @@has_tail in Object (NameError)

Guess it has something to do with ghost classes in the second case, so defining singleton within class def as self.method and as Class.method are quite different?

Recent Posts in The Ruby Object Model and Metaprogramming | Pragmatic Forums

inherited - any class posted by Dave Thomas @ Fri, 21 Nov 2008 14:28:20 -0000

inherited - any class posted by Michael Stramba @ Fri, 21 Nov 2008 03:14:43 -0000

My heartfelt thanks to Dave posted by Todd W Crone @ Tue, 28 Oct 2008 14:13:52 -0000

Call old mehod added posted by Jon Stenqvist @ Sun, 19 Oct 2008 09:57:23 -0000

My heartfelt thanks to Dave posted by Nate Kidwell @ Sun, 21 Sep 2008 16:19:04 -0000

Episode 6 posted by Jon Stenqvist @ Tue, 09 Sep 2008 18:23:39 -0000

Episode 6 posted by Jon Stenqvist @ Mon, 08 Sep 2008 17:51:17 -0000

Episode 6 posted by Dave Thomas @ Mon, 08 Sep 2008 03:35:25 -0000

Episode 6 posted by Jon Stenqvist @ Sun, 07 Sep 2008 20:46:03 -0000

An idea for a future installment posted by Ira Davis @ Wed, 03 Sep 2008 21:20:04 -0000

A bit off-topic posted by Dave Thomas @ Tue, 05 Aug 2008 12:55:56 -0000

A bit off-topic posted by Mathijs Kwik @ Tue, 05 Aug 2008 07:00:18 -0000

Not sure how to interpret this? posted by Bharat Ruparel @ Fri, 01 Aug 2008 15:52:04 -0000

Not sure how to interpret this? posted by James Whiteman @ Mon, 28 Jul 2008 16:13:36 -0000

Not sure how to interpret this? posted by Bharat Ruparel @ Sat, 26 Jul 2008 02:07:24 -0000

Not sure how to interpret this? posted by Bharat Ruparel @ Tue, 22 Jul 2008 19:41:34 -0000

Not sure how to interpret this? posted by Dave Thomas @ Tue, 22 Jul 2008 03:36:03 -0000

Not sure how to interpret this? posted by Bharat Ruparel @ Tue, 22 Jul 2008 01:35:40 -0000

Why cool guys use obj.instance_eval instead of class << obj to define singletons? posted by Dave Thomas @ Sun, 20 Jul 2008 22:47:06 -0000

Why cool guys use obj.instance_eval instead of class << obj to define singletons? posted by Victor Moroz @ Sun, 20 Jul 2008 19:10:44 -0000

Why cool guys use obj.instance_eval instead of class << obj to define singletons? posted by Dave Thomas @ Sun, 20 Jul 2008 16:06:19 -0000

Why cool guys use obj.instance_eval instead of class << obj to define singletons? posted by Victor Moroz @ Sun, 20 Jul 2008 07:45:20 -0000

Why cool guys use obj.instance_eval instead of class << obj to define singletons? posted by Victor Moroz @ Sun, 20 Jul 2008 07:11:58 -0000

Using @@var inside class definition posted by Victor Moroz @ Sun, 20 Jul 2008 03:53:11 -0000

Using @@var inside class definition posted by Victor Moroz @ Sat, 19 Jul 2008 19:16:02 -0000