Class << self?

ruby-talk
1

Can someone please explain exactly what "class << self" does , I just
dont get it.

I was trying to alias some static methods with no luck but later found
some webpage saying that I need "class << self" to make the code run in
a static context.

I know that even if I make a static method inside Class, there is still
a "self" object , so I guess even though Im in a static method it
somehow belongs to the class object that represents the type Im calling
my static method on?

eg:

MyType.my_static_method(); #<- will execute in the context of the Class
instance "MyType" ?, or???

and when I do class << self , I'll enter the static context of "MyType"
, meaning "self" would no longer be "MyType" ?

and even if that is the case, why are all my local variables out of
scope inside that block?
I mean its still the same method that executes, or are the variables
somehow bound to the objects in which the method executes, even if they
are method local?

Im really confused here :slight_smile:

//Roger

···

--
Posted via http://www.ruby-forum.com/.

2

alias static method:

class Test
  def self.foo
    puts "foo"
  end

end

class Test
  class << self
    alias :bar :foo
  end
end

Test.bar

Roger Johansson schrieb:

···

Can someone please explain exactly what "class << self" does , I just dont get it.

I was trying to alias some static methods with no luck but later found some webpage saying that I need "class << self" to make the code run in a static context.

I know that even if I make a static method inside Class, there is still a "self" object , so I guess even though Im in a static method it somehow belongs to the class object that represents the type Im calling my static method on?

eg:

MyType.my_static_method(); #<- will execute in the context of the Class instance "MyType" ?, or???

and when I do class << self , I'll enter the static context of "MyType" , meaning "self" would no longer be "MyType" ?

and even if that is the case, why are all my local variables out of scope inside that block?
I mean its still the same method that executes, or are the variables somehow bound to the objects in which the method executes, even if they are method local?

Im really confused here :slight_smile:

//Roger

3

It looks like I'm really late in responding, but David is being too modest - his book, "Ruby for Rails" is absolutely excellent in discussing this (and other!) advanced Ruby topics. It's most definitely worth the purchase price, imo.

···

On Jun 23, 2006, at 3:10 PM, Roger Johansson wrote:

Can someone please explain exactly what "class << self" does , I just
dont get it.

--
Jason Perkins
jperkins@sneer.org

"The computer allows you to make mistakes
faster than any other invention, with the
possible exception of handguns and tequila."

-Mitch Ratcliffe

4

thanks, Ive figured this part out.

but what exactly does the class << self do? why do I need it, why cant I
just do "alias bla,orig" on static methods directly?

···

--
Posted via http://www.ruby-forum.com/.

5

I should clarify that my previous statement doesn't exclude the Pickaxe for it's content on that material. I wrote that assuming that you were already consulting it. When encountering new concepts, I want as much information from smart, competent people that I can get.

···

On Jun 25, 2006, at 9:48 AM, Jason Perkins wrote:

On Jun 23, 2006, at 3:10 PM, Roger Johansson wrote:

Can someone please explain exactly what "class << self" does , I just
dont get it.

It looks like I'm really late in responding, but David is being too modest - his book, "Ruby for Rails" is absolutely excellent in discussing this (and other!) advanced Ruby topics. It's most definitely worth the purchase price, imo.

--
Jason Perkins
jperkins@sneer.org

"The computer allows you to make mistakes
faster than any other invention, with the
possible exception of handguns and tequila."

-Mitch Ratcliffe

6

Data is stored in objects. Code is stored in classes. You can't
store data in classes and you can't store code in objects. It's
just that simple.

But...

Let's have a look at this code:

foo = Foo.new
def foo.bar
   # code...
end
foo.bar

This adds method bar to foo. Not to Foo, but to "that specific
instance of Foo". Uh, that doesn't match very well with my
first statement about class and objects, does it?

So Matz gave us meta classes, or anonymous classes, or, virtual
classes. Different names for the same thing. Every Object can
have a classes of its own where it can store code. That's the
trick.

You can rewrite the previous code to the following example,
which more explicitly shows the anonymous class:

foo = Foo.new
class << foo
   def bar
     # code...
   end
end
foo.bar

Since Foo is an object of class Class, it can have it's own
class, too. That's where class methods (static methods for Java
Joe...) go:

class << Foo
   def bar
     # code...
   end
end
Foo.bar

The object (!) Foo has a method of its own, stored in its own
anonymous class and not in class Class (which would affect
other classes as well).

Print the following article, take a good cigar, a good glass of
beer, preferably Dutch beer, and read... Over and over again...

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

gegroet,
Erik V. - http://www.erikveen.dds.nl/

···

On Sat, 2006-06-24 at 05:36 +0900, Roger Johansson wrote:

thanks, Ive figured this part out.

but what exactly does the class << self do? why do I need it,
why cant I just do "alias bla,orig" on static methods
directly?

7

Hi --

thanks, Ive figured this part out.

but what exactly does the class << self do? why do I need it,
why cant I just do "alias bla,orig" on static methods
directly?

Data is stored in objects. Code is stored in classes. You can't
store data in classes and you can't store code in objects. It's
just that simple.

Classes are objects, though (as you point out later in a slightly
different context), so they can store data:

   class C
     @x = 1
   end

But...

Let's have a look at this code:

foo = Foo.new
def foo.bar
  # code...
end
foo.bar

This adds method bar to foo. Not to Foo, but to "that specific
instance of Foo". Uh, that doesn't match very well with my
first statement about class and objects, does it?

So Matz gave us meta classes, or anonymous classes, or, virtual
classes. Different names for the same thing.

Namely, singleton classes :slight_smile: (I know, I know.)

Every Object can have a classes of its own where it can store code.
That's the trick.

Those terms aren't interchangeable, though; a class can be anonymous
without being the singleton class of an object:

   Class.new

Singleton classes are anonymous, but anonymous classes aren't always
singleton classes.

David

···

On Sat, 24 Jun 2006, Erik Veenstra wrote:

On Sat, 2006-06-24 at 05:36 +0900, Roger Johansson wrote:

--
David A. Black (dblack@wobblini.net)
Ruby Power and Light, LLC (http://www.rubypowerandlight.com)

See what the readers are saying about "Ruby for Rails"!

8

Ok, thanks I think im sort of getting the picture now :stuck_out_tongue:

"MyType" is an instance of class "Class".
this instance has a metaclass , which holds the static methods for
MyType.

eg in pseudo c#ish code:

RubyClass MyType = new RubyClass();
MyType.Meta = new RubyMetaClass();
MyType.Meta.StaticMethods.Add("some_method",args);

would that be a correct view of the object/class relations in this case?

this seems fair enough but what I dont get is why are static methods and
instance methods stored in different places?

in other languages(or rather implementations of languages) instance
methods are just syntax sugar for a static method with a "this" pointer
as the first arg. but they are still stored at the same palce.

what I dont get is why I only need to do the "class << self" thing when
aliasing static methods and not instance methods.

Why are the instance methods accessable in the context of MyType ?

...hmmm.. maybe I get it now ..

the meta class is a runtime class which has the actual static methods as
real methods , not just a list of methods as in my pseudo sample?

it would be more like:

RubyClass MyType = new RubyClass();
MyType.Meta = new ConcreteMetaClassForMyType(); //<--

and every call to a static method is just directed to the meta class?
and since MyType is not only an instance of Class , it is also a
"class",
so MyType is a class that has the instance methods.
and the meta has the static methods of MyType as instance methods?

or should I go to sleep now?
this is weird :stuck_out_tongue:

//Roger

···

--
Posted via http://www.ruby-forum.com/.

9

Hi --

Ok, thanks I think im sort of getting the picture now :stuck_out_tongue:

"MyType" is an instance of class "Class".
this instance has a metaclass , which holds the static methods for
MyType.

eg in pseudo c#ish code:

RubyClass MyType = new RubyClass();
MyType.Meta = new RubyMetaClass();
MyType.Meta.StaticMethods.Add("some_method",args);

would that be a correct view of the object/class relations in this case?

this seems fair enough but what I dont get is why are static methods and
instance methods stored in different places?

in other languages(or rather implementations of languages) instance
methods are just syntax sugar for a static method with a "this" pointer
as the first arg. but they are still stored at the same palce.

what I dont get is why I only need to do the "class << self" thing when
aliasing static methods and not instance methods.

Why are the instance methods accessable in the context of MyType ?

...hmmm.. maybe I get it now ..

the meta class is a runtime class which has the actual static methods as
real methods , not just a list of methods as in my pseudo sample?

it would be more like:

RubyClass MyType = new RubyClass();
MyType.Meta = new ConcreteMetaClassForMyType(); //<--

and every call to a static method is just directed to the meta class?
and since MyType is not only an instance of Class , it is also a
"class",
so MyType is a class that has the instance methods.
and the meta has the static methods of MyType as instance methods?

or should I go to sleep now?
this is weird :stuck_out_tongue:

I'm tired too (and a little spacy, having just spent 1.5 hours at a
Why the Lucky Stiff performance :slight_smile: But I can give you this advice:
forget the term "static method". It only clouds the picture. Other
than that, you're very close.

Every object (almost, but don't worry about the exceptions right now)
can have its own methods, as well as the methods it gets from its
class. The way Ruby organizes this special category of
object-specific methods is by creating an object-specific class.

It's that object-specific class that you gain access to when you do:

   class << some_object

You're inside some_object's singleton class -- that is, the class
where the singleton methods of some_object are defined.

some_object can be (but does not have to be) a Class object. When you
see:

   class SomeClass
     class << self
       def whatever

you're seeing the singleton method "whatever" being added to the
object SomeClass, courtesy of opening up that object's singleton class
and defining a method there.

David

···

On Sat, 24 Jun 2006, Roger Johansson wrote:

--
David A. Black (dblack@wobblini.net)
Ruby Power and Light, LLC (http://www.rubypowerandlight.com)

See what the readers are saying about "Ruby for Rails"!

10

Roger Johansson schrieb:

...
what I dont get is why I only need to do the "class << self" thing when aliasing static methods and not instance methods.

Roger, I think you haven't gotten an answer to this part of your question yet. I'm sure you wouldn't expect the alias keyword at the instance level in order to create an alias for an instance method:

   class C
     def m
       ...
     end
   end

   c = C.new
   c.alias :mnew :m # create alias for the instance method C#m,
                     # but only for the instance c, or for all
                     # instances of C ???

So it makes sense to have the alias keyword where methods are normally defined: at the module/class level:

   class C
     def m
       ...
     end
   end

   class C
     alias :mnew :m # create alias for the instance method C#m
   end

The same applies to singleton methods:

   o = Object.new

   class << o
     def m
       ...
     end
   end

   class << o
     alias :mnew :m # create alias for the singleton method o.m
   end

The only difference to instance methods is that you can define singleton methods with an additional syntax:

   def o.m
     ...
   end

Now, what you call "static methods" are simply singleton methods of class objects, so again the same mechanisms apply:

   C = Class.new

   class << C
     def m
       ...
     end
   end

   class << C
     alias :mnew :m # create alias for singleton method C.m
   end

I've used the same syntax as in the example above to show the similarity to other singleton methods. Normally you'd write this as:

   class C
     class << self
       def m
         ...
       end
     end
   end

   class C
     class << self
       alias :mnew :m # create alias for singleton method C.m
     end
   end

or, for the definition part, as:

   class C
     def self.m
       ...
     end
   end

or even:

   def C.m
     ...
   end

As others have noted, just forget about "static methods". They don't exist in Ruby. There are only instance methods and singleton methods, nothing more.

Feel free to ask again if it's not clear.

Regards,
Pit

11

Thanks,

I think Ive gotten the hang of it now.
I watched the ascii art image in the ruby core doc for "Class"

The reason I got confused was because its pretty much the inverse of how
other languages works..

in other language implementations there are only static methods and no
real instance methods (they just pass a "this" pointer to a static
method)

and here in ruby there are only instance methods and no real static
methods
so it makes sense that the instance methods and singleton methods live
in different contexts here.

//Roger

···

--
Posted via http://www.ruby-forum.com/.