A question about Class and Object

ruby-talk
1

Hello!

I found a strange thing.

Object.class
=>Class
Class.class
=>Class

As you see, Object and Class are of same type.

Object.methods.length
=>73
Class.methods.length
=>74
Class.methods - Object.methods
=>["nesting"]

I expected that Object has same methods as Class but it's not.
Can somebody explain and teach me please?

Thanks in advance.

kong

2

See Module#nesting in ri

irb(main):001:0> Object.ancestors
=> [Object, Kernel]
irb(main):002:0> Class.ancestors
=> [Class, Module, Object, Kernel]

Class and Module have a nesting, while classes not descended from Class
or Module do not.

···

Sam Sungshik Kong (ssk@chol.nospam.net) wrote:

Hello!

I found a strange thing.

Object.class
=>Class
Class.class
=>Class

As you see, Object and Class are of same type.

Object.methods.length
=>73
Class.methods.length
=>74
Class.methods - Object.methods
=>["nesting"]

I expected that Object has same methods as Class but it's not.
Can somebody explain and teach me please?

--
Eric Hodel - drbrain@segment7.net - http://segment7.net
All messages signed with fingerprint:
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04

3

You should care about superclass, not class:

$ irb
irb(main):001:0> Object.superclass
=> nil
irb(main):002:0> Class.superclass
=> Module
irb(main):003:0>

Cheers,
Kent.

···

On Jun 21, 2004, at 4:08 PM, Sam Sungshik Kong wrote:

Hello!

I found a strange thing.

Object.class
=>Class
Class.class
=>Class

As you see, Object and Class are of same type.

Object.methods.length
=>73
Class.methods.length
=>74
Class.methods - Object.methods
=>["nesting"]

I expected that Object has same methods as Class but it's not.
Can somebody explain and teach me please?

Thanks in advance.

kong

4

What version of Ruby are you running? From irb,
Object.class.methods.length return 74.

Instances of Object and Class should not necessarily have the same
number of methods, but Object.class and Class.class should since they
both return an instance of Class. The exception being somewhere
someone added or a removed a method from the instance of Class
returned by Object.class.

···

On Tue, 22 Jun 2004 05:08:21 +0900, Sam Sungshik Kong <ssk@chol.nospam.net> wrote:

Hello!

I found a strange thing.

Object.class
=>Class
Class.class
=>Class

As you see, Object and Class are of same type.

Object.methods.length
=>73
Class.methods.length
=>74
Class.methods - Object.methods
=>["nesting"]

I expected that Object has same methods as Class but it's not.
Can somebody explain and teach me please?

Thanks in advance.

kong

5

"Sam Sungshik Kong" <ssk@chol.nospam.net> schrieb im Newsbeitrag
news:paHBc.6843$_e1.3669@newssvr27.news.prodigy.com...

Hello!

I found a strange thing.

Object.class
=>Class
Class.class
=>Class

As you see, Object and Class are of same type.

Object.methods.length
=>73
Class.methods.length
=>74
Class.methods - Object.methods
=>["nesting"]

I expected that Object has same methods as Class but it's not.
Can somebody explain and teach me please?

There is also a general answer in Ruby: even if two instances belong to
the same class they need not have the same number of methods, because
methods can be defined on a per instance basis. Consider:

irb(main):015:0> class Foo; def test; "test"; end; end
=> nil
irb(main):016:0> f1 = Foo.new
=> #<Foo:0x1016f920>
irb(main):017:0> f2 = Foo.new
=> #<Foo:0x1016c788>
irb(main):018:0> class << f2; def test2; "test2"; end; end
=> nil
irb(main):019:0> f1.class
=> Foo
irb(main):020:0> f2.class
=> Foo
irb(main):021:0> f1.methods.grep(/test/)
=> ["test"]
irb(main):022:0> f2.methods.grep(/test/)
=> ["test2", "test"]
irb(main):023:0> f2.methods - f1.methods
=> ["test2"]

Regards

    robert

6

Thanks for your reply.
But I still don't understand it very well.

Object is type of Class, right?
(Object.class -> Class)
Class has a method - nesting.
Then Object should have it because it's type of Class.

Maybe something in my logic is wrong.
Could you point me to it?

kong

"Kent Sibilev" <ksibilev@bellsouth.net> wrote in message
news:E49B7180-C3C0-11D8-8F8A-000A95C700E8@bellsouth.net...

···

You should care about superclass, not class:

$ irb
irb(main):001:0> Object.superclass
=> nil
irb(main):002:0> Class.superclass
=> Module
irb(main):003:0>

Cheers,
Kent.

On Jun 21, 2004, at 4:08 PM, Sam Sungshik Kong wrote:

> Hello!
>
> I found a strange thing.
>
> Object.class
> =>Class
> Class.class
> =>Class
>
> As you see, Object and Class are of same type.
>
> Object.methods.length
> =>73
> Class.methods.length
> =>74
> Class.methods - Object.methods
> =>["nesting"]
>
> I expected that Object has same methods as Class but it's not.
> Can somebody explain and teach me please?
>
> Thanks in advance.
>
> kong
>
>
>

7

Hi!

I'm using Ruby 1.8.

Object.class.methods.length #->74
Object.methods.length #->73

Object.class is Class.
Object is type of Class.

I'm still confused with class and object and metaclass...

Sam
"wilkes joiner" <wilkesjoiner@gmail.com> wrote in message
news:b832a2c7040621165233d5a0a5@mail.gmail.com...

···

What version of Ruby are you running? From irb,
Object.class.methods.length return 74.

Instances of Object and Class should not necessarily have the same
number of methods, but Object.class and Class.class should since they
both return an instance of Class. The exception being somewhere
someone added or a removed a method from the instance of Class
returned by Object.class.

On Tue, 22 Jun 2004 05:08:21 +0900, Sam Sungshik Kong > <ssk@chol.nospam.net> wrote:
>
> Hello!
>
> I found a strange thing.
>
> Object.class
> =>Class
> Class.class
> =>Class
>
> As you see, Object and Class are of same type.
>
> Object.methods.length
> =>73
> Class.methods.length
> =>74
> Class.methods - Object.methods
> =>["nesting"]
>
> I expected that Object has same methods as Class but it's not.
> Can somebody explain and teach me please?
>
> Thanks in advance.
>
> kong
>
>

8

Hi!

Thank you for the explanation.
Now I understand the concept...maybe...:slight_smile:

I think that Class is a very unique one.
All other classes are an instance of Class (Object is an instance of Class).
What about Class?
It's an instance of itself, right?
Class is a concept as well as a thing.

To test this strange thing, I tried to subclass Class but it failed.

class MyClass < Class
end
=>TypeError: can't make subclass of Class

Now, I created an instance of Class.

aClass = Class.new

Is aClass a class like Object or just an object like obj (obj = Object.new)?

It seems like a class.

aaClass = aClass.new #->Works!

So Class is actually a class maker.
It's instances are classes.
That means that to make a class, I don't have to define a class.
If I just create an instance of Class, it's a class.

When I think of Class and Object, the "chicken and egg" problem comes to my
mind.
Object is an instance of Class and Class inherits from Object.
Which one is first? (Which one should exist first?)

I am sorry that what I said is not very structured.

Sam

"Robert Klemme" <bob.news@gmx.net> wrote in message
news:2jq7gfF14nmiuU1@uni-berlin.de...

···

"Sam Sungshik Kong" <ssk@chol.nospam.net> schrieb im Newsbeitrag
news:paHBc.6843$_e1.3669@newssvr27.news.prodigy.com...
> Hello!
>
> I found a strange thing.
>
> Object.class
> =>Class
> Class.class
> =>Class
>
> As you see, Object and Class are of same type.
>
> Object.methods.length
> =>73
> Class.methods.length
> =>74
> Class.methods - Object.methods
> =>["nesting"]
>
> I expected that Object has same methods as Class but it's not.
> Can somebody explain and teach me please?

There is also a general answer in Ruby: even if two instances belong to
the same class they need not have the same number of methods, because
methods can be defined on a per instance basis. Consider:

irb(main):015:0> class Foo; def test; "test"; end; end
=> nil
irb(main):016:0> f1 = Foo.new
=> #<Foo:0x1016f920>
irb(main):017:0> f2 = Foo.new
=> #<Foo:0x1016c788>
irb(main):018:0> class << f2; def test2; "test2"; end; end
=> nil
irb(main):019:0> f1.class
=> Foo
irb(main):020:0> f2.class
=> Foo
irb(main):021:0> f1.methods.grep(/test/)
=> ["test"]
irb(main):022:0> f2.methods.grep(/test/)
=> ["test2", "test"]
irb(main):023:0> f2.methods - f1.methods
=> ["test2"]

Regards

    robert

9

Class inherits from Module, Object does not. A Module has a nesting,
while an object does not (unless it is a Class or Module).

See Module#nesting in ri.

···

Sam Sungshik Kong (ssk@chol.nospam.net) wrote:

Thanks for your reply.
But I still don't understand it very well.

Object is type of Class, right?
(Object.class -> Class)
Class has a method - nesting.
Then Object should have it because it's type of Class.

Maybe something in my logic is wrong.
Could you point me to it?

--
Eric Hodel - drbrain@segment7.net - http://segment7.net
All messages signed with fingerprint:
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04

10

Hi Sam --

The key is that what class an object is doesn't say everything about
what methods it has, because of the existence of singleton methods.
[And the list of methods an object has doesn't say everything about
what messages it responds to, because of the existence of
method_missing - though this is irrelevant to your question :)] James
Britt's recent message http://www.ruby-talk.org/104273 explains this,
though without mentioning singleton methods explicitly.

In this case, the additional method ("nesting") is sneaking in as
singleton method on Module:

irb(main):015:0> Module.singleton_methods
=> ["constants", "nesting"]

constants is also a Module singleton method, but nesting is the only
new one:

irb(main):016:0> Object.methods.include?("nesting")
=> false
irb(main):017:0> Object.methods.include?("constants")
=> true

... hence the difference of 1 in the number of methods that Object and
Module have.

Hope this helps,

George.

···

"Sam Sungshik Kong" <ssk@chol.nospam.net> wrote

I'm using Ruby 1.8.

Object.class.methods.length #->74
Object.methods.length #->73

Object.class is Class.
Object is type of Class.

I'm still confused with class and object and metaclass...

11

I'm still confused with class and object and metaclass...

well, try to forget about metaclass.

I'll try to give you a *STUPID* explanation

ruby has only objects, this mean that a class is an object and like any
object it has a class (Class) where are defined its methods.

This mean that, for example, the method ::new is defined in Class,
something like this

   class Class
      def new(*args, &block)
         obj = allocate
         obj.send(:initialize, *args, &block)
         obj
      end
   end

This work fine, but you see that it exist a problem. If it was easy to
define ::new, it will be more difficult to define ::allocate in the same
way, because Array::allocate is completely different from Hash::allocate
and you don't want to define a method Class#allocate with a big switch and
change this method each time that you introduce a new class

Another problem if that it will be nice if you can define a method
File::open, which take a block. You can't define this method in Class
(i.e. Class#open) because this mean that you'll define also Array::open,
Hash::open and you don't want this.

To solve these 2 problems, ruby associate with each class an object and
when it search a class method it search first in this object then it look
in Class.

Now ruby can work, because
   * the method ::allocate will be defined in this special object, and you
     still have Class#new

   * you can define in the object associated with File, the method ::open
     and only this class will have this method

But a class is a little special because there is inheritence and when you
write

    class A < Array
    end

you want to re-use, for A, the method ::allocate which was defined in the
special object associated with Array

This mean that for this special object, associated with a class, you want
   * the possibility to define method
   * the possibility to use inheritence

an object is well adapted to do this, this is precisely a class and
because this class will always be associated with only *one* other object
it will called a "singleton" class

Finally this give this (where (A) is the singleton class associated with
A)

    Class < Module < Object
   (Class) < (Module) < (Object) < Class
                               
      A < Array < Object
     (A) < (Array) < (Object)

and you have the schema which is given in object.c

Now, at the beginning, I've said that a class is an object and I've
introduced the singleton class. This mean that you can associate a
singleton class with any object, and this will give methods specifics to
this object, for example

   a =
   class << a
      def tt
      end
   end

When ruby will search a method for `a', it will first search in its
singleton class then in its class.

Guy Decoux

12

aaClass = aClass.new #->Works!

   foo = Class.new do
     define_method :initialize do |color|
       @color = color
     end
   end
     #=>#<Class:0x5f494>

   red_foo = foo.new(:red)
     #=>#<#<Class:0x5f494>:0x5ce10 @color=:red>

You can create classes and add methods to them by just passing blocks to method calls :slight_smile:

Note that you need to be very careful if you do things this way... both the class and the initialize method were defined using blocks, so they use the current binding. So if you had a local variable named 'color' set...

So Class is actually a class maker.
It's instances are classes.
That means that to make a class, I don't have to define a class.
If I just create an instance of Class, it's a class.

When I think of Class and Object, the "chicken and egg" problem comes to my
mind.
Object is an instance of Class and Class inherits from Object.
Which one is first? (Which one should exist first?)

yes, I agree... the mind boggles :slight_smile:

cheers,
Mark

···

On Jun 22, 2004, at 9:28 AM, Sam Sungshik Kong wrote:

13

Sam Sungshik Kong wrote:

[snip]

When I think of Class and Object, the "chicken and egg" problem comes to my
mind.
Object is an instance of Class and Class inherits from Object.
Which one is first? (Which one should exist first?)

I am sorry that what I said is not very structured.

I think this was well said. Personally I have been using Ruby for nearly
five years, and this area still confuses me frequently.

Hal

14

"Sam Sungshik Kong" <ssk@chol.nospam.net> schrieb im Newsbeitrag
news:U5ZBc.76284$zo2.55015@newssvr29.news.prodigy.com...

Hi!

Thank you for the explanation.
Now I understand the concept...maybe...:slight_smile:

I think that Class is a very unique one.
All other classes are an instance of Class (Object is an instance of

Class).

What about Class?
It's an instance of itself, right?
Class is a concept as well as a thing.

Yes, it's self referencing:

irb(main):001:0> Class.class
=> Class
irb(main):002:0> Class.id == Class.class.id
=> true
irb(main):003:0> Class.ancestors
=> [Class, Module, Object, Kernel]

To test this strange thing, I tried to subclass Class but it failed.

class MyClass < Class
end
=>TypeError: can't make subclass of Class

Now, I created an instance of Class.

aClass = Class.new

Is aClass a class like Object or just an object like obj (obj =

Object.new)?

It seems like a class.

Right.

aaClass = aClass.new #->Works!

Note, that there is some magic involved depending on whether you assign to
a constant or a variable:

irb(main):001:0> Foo = Class.new
=> Foo
irb(main):002:0> Foo.name
=> "Foo"
irb(main):003:0> Foo.new.class
=> Foo
irb(main):004:0> foo = Class.new
=> #<Class:0x10182f00>
irb(main):005:0> foo.name
=> ""
irb(main):006:0> foo.new.class
=> #<Class:0x10182f00>

i.e. if the class instance is assigned a constant it's a named class,
otherwise it's an anonymous class.

So Class is actually a class maker.
It's instances are classes.
That means that to make a class, I don't have to define a class.
If I just create an instance of Class, it's a class.

Yes.

When I think of Class and Object, the "chicken and egg" problem comes to

my

mind.
Object is an instance of Class and Class inherits from Object.
Which one is first? (Which one should exist first?)

I am sorry that what I said is not very structured.

Well, that's normal as soon as self referencingness comes into play. :slight_smile:
In fact, Class and Object are special in the way that the Ruby interpreter
ensures they are there and can reference one another before any user Ruby
code is executed (especially class definitions). So you can just use them
like other classes and don't have to worry about these specialities.

Kind regards

    robert

Sam

"Robert Klemme" <bob.news@gmx.net> wrote in message
news:2jq7gfF14nmiuU1@uni-berlin.de...
>
> "Sam Sungshik Kong" <ssk@chol.nospam.net> schrieb im Newsbeitrag
> news:paHBc.6843$_e1.3669@newssvr27.news.prodigy.com...
> > Hello!
> >
> > I found a strange thing.
> >
> > Object.class
> > =>Class
> > Class.class
> > =>Class
> >
> > As you see, Object and Class are of same type.
> >
> > Object.methods.length
> > =>73
> > Class.methods.length
> > =>74
> > Class.methods - Object.methods
> > =>["nesting"]
> >
> > I expected that Object has same methods as Class but it's not.
> > Can somebody explain and teach me please?
>
> There is also a general answer in Ruby: even if two instances belong

to

···

> the same class they need not have the same number of methods, because
> methods can be defined on a per instance basis. Consider:
>
> irb(main):015:0> class Foo; def test; "test"; end; end
> => nil
> irb(main):016:0> f1 = Foo.new
> => #<Foo:0x1016f920>
> irb(main):017:0> f2 = Foo.new
> => #<Foo:0x1016c788>
> irb(main):018:0> class << f2; def test2; "test2"; end; end
> => nil
> irb(main):019:0> f1.class
> => Foo
> irb(main):020:0> f2.class
> => Foo
> irb(main):021:0> f1.methods.grep(/test/)
> => ["test"]
> irb(main):022:0> f2.methods.grep(/test/)
> => ["test2", "test"]
> irb(main):023:0> f2.methods - f1.methods
> => ["test2"]
>
> Regards
>
> robert
>

15

Sam,

'Object', 'Module', and 'Class' are all components of Ruby's
meta-object protocol, so the relationships between them are a special
case. 'Object.class' returns 'Class', but internally, the Object type
is created in the C code that initializes the object model, before
that model is complete.

In other words, a few core classes must be bootstrapped in the runtime
to avoid circular inheritance relationships. That can make them appear
to violate the usual semantics, but there is really no way aside from
layering a class-based object model on top of a simpler one (such as
simple prototypes) to avoid having certain primitives with special
status and semantics.

Lennon

16

I don't think it's a stupid explanation...:slight_smile:
It's just above my intelligence.
I'll keep learning Ruby and someday I'll understand it.

Thanks.

Sam
"ts" <decoux@moulon.inra.fr> wrote in message
news:200406220934.i5M9Y7r02023@moulon.inra.fr...

> I'm still confused with class and object and metaclass...

well, try to forget about metaclass.

I'll try to give you a *STUPID* explanation

ruby has only objects, this mean that a class is an object and like any
object it has a class (Class) where are defined its methods.

This mean that, for example, the method ::new is defined in Class,
something like this

   class Class
      def new(*args, &block)
         obj = allocate
         obj.send(:initialize, *args, &block)
         obj
      end
   end

This work fine, but you see that it exist a problem. If it was easy to
define ::new, it will be more difficult to define ::allocate in the same
way, because Array::allocate is completely different from Hash::allocate
and you don't want to define a method Class#allocate with a big switch

and

···

change this method each time that you introduce a new class

Another problem if that it will be nice if you can define a method
File::open, which take a block. You can't define this method in Class
(i.e. Class#open) because this mean that you'll define also Array::open,
Hash::open and you don't want this.

To solve these 2 problems, ruby associate with each class an object and
when it search a class method it search first in this object then it look
in Class.

Now ruby can work, because
   * the method ::allocate will be defined in this special object, and you
     still have Class#new

   * you can define in the object associated with File, the method ::open
     and only this class will have this method

But a class is a little special because there is inheritence and when you
write

    class A < Array
    end

you want to re-use, for A, the method ::allocate which was defined in the
special object associated with Array

This mean that for this special object, associated with a class, you want
   * the possibility to define method
   * the possibility to use inheritence

an object is well adapted to do this, this is precisely a class and
because this class will always be associated with only *one* other object
it will called a "singleton" class

Finally this give this (where (A) is the singleton class associated with
A)

    Class < Module < Object
   (Class) < (Module) < (Object) < Class

      A < Array < Object
     (A) < (Array) < (Object)

and you have the schema which is given in object.c

Now, at the beginning, I've said that a class is an object and I've
introduced the singleton class. This mean that you can associate a
singleton class with any object, and this will give methods specifics to
this object, for example

   a =
   class << a
      def tt
      end
   end

When ruby will search a method for `a', it will first search in its
singleton class then in its class.

Guy Decoux

17

Thank you!

I was very close to it.
And you assured me.

Actually http://www.ruby-talk.org/104273 was in the thread that I
started...:slight_smile:
I liked his explanation.

Sam

"George Marrows" <george.marrows@ps.ge.com> wrote in message
news:5e44d1a4.0406220019.47fdb543@posting.google.com...

···

"Sam Sungshik Kong" <ssk@chol.nospam.net> wrote

> I'm using Ruby 1.8.
>
> Object.class.methods.length #->74
> Object.methods.length #->73
>
> Object.class is Class.
> Object is type of Class.
>
> I'm still confused with class and object and metaclass...

Hi Sam --

The key is that what class an object is doesn't say everything about
what methods it has, because of the existence of singleton methods.
[And the list of methods an object has doesn't say everything about
what messages it responds to, because of the existence of
method_missing - though this is irrelevant to your question :)] James
Britt's recent message http://www.ruby-talk.org/104273 explains this,
though without mentioning singleton methods explicitly.

In this case, the additional method ("nesting") is sneaking in as
singleton method on Module:

irb(main):015:0> Module.singleton_methods
=> ["constants", "nesting"]

constants is also a Module singleton method, but nesting is the only
new one:

irb(main):016:0> Object.methods.include?("nesting")
=> false
irb(main):017:0> Object.methods.include?("constants")
=> true

.. hence the difference of 1 in the number of methods that Object and
Module have.

Hope this helps,

George.

18

wow, this was a wonderful explanation, thanks

Yet, it looks to much verbose for the ts that we
used to read, what's happening ? :slight_smile:

···

il Tue, 22 Jun 2004 18:34:13 +0900, ts <decoux@moulon.inra.fr> ha scritto::