Pragmatic Forums | Posts in forum 'The Ruby Object Model and Metaprogramming'

Episode 4 minor errata posted by Giang NGUYEN @ Sun, 01 Jul 2012 16:01:02 +0000

Giang NGUYEN — Sun, 01 Jul 2012 16:01:32 +0000

Episode 5: Careful with the cache. posted by Cassiano D'Andrea @ Wed, 13 Jun 2012 03:10:33 +0000

Cassiano D'Andrea — Wed, 13 Jun 2012 12:20:45 +0000

Episode 5: Careful with the cache. posted by Dave Thomas @ Tue, 12 Jun 2012 14:53:34 +0000

Dave Thomas — Tue, 12 Jun 2012 14:53:34 +0000

Episode 5: Careful with the cache. posted by Cassiano D'Andrea @ Tue, 12 Jun 2012 14:04:21 +0000

Cassiano D'Andrea — Tue, 12 Jun 2012 14:40:01 +0000

Episode 1: Current Class posted by Dave Thomas @ Wed, 01 Feb 2012 14:11:18 +0000

Dave Thomas — Wed, 01 Feb 2012 14:11:18 +0000

There’s no reflection built in to Ruby to let you get to the current class. It would be cool if there was.

Episode 1: Object Diagram posted by Dave Thomas @ Wed, 01 Feb 2012 14:10:27 +0000

Dave Thomas — Wed, 01 Feb 2012 14:10:27 +0000

Yes, String is an instance of object. But it is also a child of Object. When we’re doing method lookup, we aren’t following “instance_of”, but we’re looking up the chain at the parent.

Episode 1: 25:50 posted by Dave Thomas @ Wed, 01 Feb 2012 14:08:21 +0000

Dave Thomas — Wed, 01 Feb 2012 14:08:21 +0000

For me, elegance comes when things are reduced to their essentials.

In most languages, dispatch to class methods is a special case. In Ruby, it isn’t. It is simpler. But it also means that things that work for regular methods work for so-called class methods, too. The orthogonality adds power.

reflection with Ruby posted by Dave Thomas @ Wed, 01 Feb 2012 14:06:25 +0000

Dave Thomas — Wed, 01 Feb 2012 14:06:25 +0000

If that’s the actual error message, then it;s simply that “columns” was misspelled.

reflection with Ruby posted by Mahesh Dsouza @ Wed, 04 Jan 2012 01:02:11 +0000

Mahesh Dsouza — Wed, 04 Jan 2012 01:02:11 +0000

Actually I should have elaborated more. Lets say I have a page which takes the name of a Model. Example -> Post . On submit I need to get all the columns associated with the Model object. So I need to somehow dynamically find the value of “Post” which is a string and dynamically translate it to a Model object. I am from a java background and new to ruby. In java you can use reflection to create such dynamic objects passing string. I tried using
model_obj = eval(“Post”) but somehow I get an error “NoMethodError (undefined method `coulmns’ for #):”. Incidentally I do the same thing using Rails console and it works. It just doesn’t work in the application. Please let me know if I am missing anything and also I want to thank you for the great screen cast it helped me a lot understanding ruby more.

reflection with Ruby posted by Dave Thomas @ Sun, 01 Jan 2012 03:00:07 +0000

Dave Thomas — Sun, 01 Jan 2012 03:00:07 +0000

What is the class of “s”? That class doesn’t support the #where method.

reflection with Ruby posted by Mahesh Dsouza @ Thu, 29 Dec 2011 17:23:15 +0000

Mahesh Dsouza — Thu, 29 Dec 2011 17:23:15 +0000

I had a question on Reflection. Assuming that I have an ActiveRecord object (Post). I know as an object we can do Post.find_by , Post.where . Can we do something like
s= “Post”
s.find_by
s.where

Episode 1: 25:50 posted by Neil H @ Fri, 16 Sep 2011 07:55:31 +0000

Neil H — Fri, 16 Sep 2011 07:55:31 +0000

In Episode 1 Dave says:
There is no such thing as class methods in Ruby. Instead all we have are singleton methods that happen to be on class objects

And when you think about it that’s incredibly cool….

Can someone elaborate why this is cool. I feel like I might be missing something fundamental.

He does elaborate a little:
There are no special cases for classes. Classes really are just objects, like any other object.

What special cases ARE there usually for classes?

I have to say, brilliant presentation, really well paced and presented, well chosen examples etc. And I am watching this episode before my first caffeine hit of the day, whilst eating cereal – so that is saying something.

Episode 4: bad diagram? posted by Felix Oghina @ Wed, 27 Apr 2011 09:22:14 +0000

Felix Oghina — Wed, 27 Apr 2011 09:22:14 +0000

At about 7:35, shouldn’t Object be above Class, and not above Dave?

Episode 1: Object Diagram posted by James D. Maher @ Mon, 07 Mar 2011 15:44:20 +0000

James D. Maher — Mon, 07 Mar 2011 15:44:20 +0000

The Object diagram is elegantly simplistic and useful.

When you introduced the diagram, you said “We always draw the class to the RIGHT of the object”. I love words like “always”; it lets me believe that concepts CAN be simple.
But, when you describe the method search (to succesive super-classes), you draw the super-class ABOVE the child class. Why not to the RIGHT?

Isn’t the String class just an instance of the Object class? So, shouldn’t each succesive super-class just be drawn to the RIGHT? Or, am I over-simplifying?

Of course, such diagrams would get very wide and unwieldy. And, you could adjust the verbiage to say “follow the arrow”. However, rigid consistency to the practice of always drawing the class to the RIGHT would absolutely crystalize the idea (at least, for me). Consistent visual repetition would really drive the point home, maybe enough for me to truly internalize the concept.

On the other hand, maybe I’m just wrong?

Jim

Episode 1: Current Class posted by James D. Maher @ Mon, 07 Mar 2011 15:26:50 +0000

James D. Maher — Mon, 07 Mar 2011 15:26:50 +0000

I learned the existence of self a while ago, and often find that asking “What’s self” helps me to work my way out of confusion (and I’m VERY easily confused). Now that you’ve revealed the existence of current class, I believe that might be equally useful.

I can simply code self
to determine “What’s self?”.

How about current class? Anyway to easily see what that is?

For example, I got excited when you showed definition of an outer_meth and declared that method WAS defined in the then current class. You said “What that class is is kinda weird, but Ruby has a current class at all levels” (sic). Well, don’t leave me guessing! WHAT is the current class when defining an outer method? Is there any way I can see what the then current class is?

BTW, I’m getting a lot out of this. I’ll re-watch in a couple days, think for the rest of the week, and watch Episode 2 next week.

Thanks so much,

Jim

Confused about defining method inside a method in episode 3 posted by Tony Eichelberger @ Wed, 28 Jul 2010 11:00:16 +0000

Tony Eichelberger — Wed, 28 Jul 2010 11:01:22 +0000

Ok, I went back to episode 1 and looked the the “concept of the current class” and realized I was thinking about method definitions the wrong way. Method definitions are put into the current open class. When using an explicit receiver, the current class changes to the singleton class of the object. With no explicit receiver, the current open class is used. The value of self at the time of a method def is not relevant.

Confused about defining method inside a method in episode 3 posted by Tony Eichelberger @ Tue, 27 Jul 2010 11:14:03 +0000

Tony Eichelberger — Tue, 27 Jul 2010 11:14:41 +0000

I am trying to understand how method definitions work in regard to the value of self. In the simple example of episode 3 where method one defines method two:


class Example
  puts "before #{self}" 
  def one
    puts "one #{self}" 
    def two
      puts "two #{self}" 
    end
  end
end

e = Example.new
e.one

f = Example.new
f.two

self is actually the instance ‘e’ when one is called the first time. I was somewhat expecting the method definition of ‘two’ to go into the singleton class for ‘e’. But then I was able to call two on a new instance ‘f’. So, inside a class definition, will self always be the class when I use the ‘def’ keyword without an explicit receiver?

Thanks.

My heartfelt thanks to Dave posted by Gavin Sinclair @ Sun, 25 Jul 2010 08:21:27 +0000

Gavin Sinclair — Sun, 25 Jul 2010 08:21:27 +0000

I’ll add my thanks. I bought the series a little while ago but just watched it over the last week. Terrific stuff.

Dave, if you’re considering a second series to cover more of this stuff (DSL examples, other hooks, ...), please consider this a nudge :)

Episode 4 minor errata posted by Zesty Volante @ Fri, 16 Jul 2010 02:12:23 +0000

Zesty Volante — Fri, 16 Jul 2010 02:54:26 +0000

At about 4:30: “We no longer need the t, because self is going to be set to t”

If self really was going to be set to t, then t.secret might actually work (it didn’t), or t.instance_eval {secret} wouldn’t work any better than t.secret did (it does).

Edit:

At about 6:10, a bit ambiguous: “Every single time you use instance_eval ruby will create one of these ghost classes and make it the class of the receiver of the instance_eval”

Ruby makes it the first class object (right identifier?) searched during method lookup, but animal.class is still String, not the anonymous ghost class. “Receiver” is the object itself (animal, or rather: “cat”); “receiver” is not the [super]class in which the method lives, no?

Episode 3 puts eval("n", two_times) 1.8.7 vs. 1.9.1 posted by Ingo Gambin @ Tue, 15 Jun 2010 05:54:57 +0000

Ingo Gambin — Tue, 15 Jun 2010 06:46:08 +0000

Ahh, yes. That looks good and somehow makes sense.

As creating a block with Proc.new shows the same behaviour, I think I’ll just stick to always using .binding then, regardless the ruby version.

Thanks a lot and best regards,

Ingo

Episode 3 puts eval("n", two_times) 1.8.7 vs. 1.9.1 posted by Dave Thomas @ Fri, 11 Jun 2010 15:19:48 +0000

Dave Thomas — Fri, 11 Jun 2010 15:19:48 +0000

I wasn’t away of the change.

It looks like 1.9 now requires that you explicitly ask for the binding of the proc as the second argument to eval


ruby-1.9.2-preview3 > def get
ruby-1.9.2-preview3 ?>  i = 99
ruby-1.9.2-preview3 ?>  lambda {}
ruby-1.9.2-preview3 ?>  end
 => nil 
ruby-1.9.2-preview3 > p = get
 => #<Proc:0x000001009e81e8@(irb):11 (lambda)> 
ruby-1.9.2-preview3 > eval("i", p.binding)
 => 99

Episode 3 puts eval("n", two_times) 1.8.7 vs. 1.9.1 posted by Ingo Gambin @ Fri, 11 Jun 2010 07:59:49 +0000

Ingo Gambin — Fri, 11 Jun 2010 07:59:49 +0000

realized that ruby 1.9.1 does not like your example

-:8:in `eval’: wrong argument type Proc (expected Binding) (TypeError) from -:8:in `<main>‘

Does that mean that in ruby 1.9.1 a lambda does not (as it does in ruby 1.8.7) create a binding?
Or is eval not anymore able to evaluate a binding from a lambda?

I am pretty new to ruby so please forgive me if my questions seem stupid… ;)

Thanks in advance and best regards,

Ingo

Object Hierarchy posted by Robert Clayton @ Wed, 19 May 2010 16:58:13 +0000

Robert Clayton — Wed, 19 May 2010 23:57:21 +0000

Dave, Thank you for you great work. I seem to be stuck on understanding one chart from Lesson 1 (25:05).
I (kind of) understand that Dave is a class object not an instantiated object. But what order of tracing would Dave.dup() take? The two parallel hierarchies confuse me as to what they are representing. Why not a single chain? I keep wanting to see Object (super) above class (sub).

Object  __    class  __
       | super:   |         | super:   |
       | class:   |<-      | class:   |<---
       | ----- |  |      | ----- |    |
       | dup()    |  |      | new()    |    |
       | frozen?()|  |      |          |    |
        __   |       __     |
                     |                      |
  Dave  __   | anon..__   |
       | super:.-|-'      | super:.--|--'
       | class: -|----->| class:     |
       | ----- |         | ------- |
       |          |         | say_hello()|
       | methods..|         |            |
        __           __

Thanks for your time.
Bob

Object Hierarchy posted by Robert Clayton @ Wed, 19 May 2010 17:00:52 +0000

Robert Clayton — Wed, 19 May 2010 23:52:44 +0000

I hope you recognize this chart it looked great in you editor window before I submitted it. In fact it still looks great when I go to edit it. So, I am not sure how to fix the appearance.

episode 2 - class variables vs. class level instance variables posted by Fred Boldireff @ Thu, 22 Apr 2010 21:59:37 +0000

Fred Boldireff — Fri, 23 Apr 2010 00:08:29 +0000

Neither did I, but I was just curious. I found an article summing up the subject (class variables vs. class level instance variables), with some interesting metaprogramming techniques that I can now decrypt thanks to your videocast. It seems the troubles arise with inheritance…