[EVALUATION] - E03c - The Ruby Object Model (Revised Documentation)

[Ilias Lazaridis]

I've not said that "Object inherits from Class nil".

I've said: Object inherits from nil

which is true.

Surely if Object inherits from nil then Object should inherit all of
nil's methods

nil.methods - Object.methods #=> ["&", "|", "^", "to_i", "to_s"]

Object.to_s #=> NoMethodError: undefined method 'to_s' for Object:Class

Since Object doesn't inherit all of nil's methods I don't see how it can
make sense to say that Object inherits from nil.

see my reply to Mr. Matsumoto:

"class Object inherits from nothing (represented by object nil)"

new diagramm:

http://lazaridis.com/case/lang/ruby/

..

 

[Ilias Lazaridis]

[EVALUATION] - E03b - The Ruby Object Model
http://groups-beta.google.com/group/comp.lang.ruby/msg/e9d841fedb35903f

-

The above thread has shown, that the existen documentation is false.

Within this page, you'll find a link to an UML diagramm

http://lazaridis.com/case/lang/ruby/

-

Please review the diagramm.

If it's correct, please ensure that the existent documentation is
corrected.

the new diagramm (needs possibly a refresh within your browser):

http://lazaridis.com/case/lang/ruby/

-

please do _not_ focus on the nil issue, but on the existing documentation.

this is covered for now with this statement:

"class Object inherits from nothing (represented by object nil)"

..

 

[Ilias Lazaridis]

Ilias Lazaridis wrote:

an example for wrong ruby documentation:

-

cmd:> ri Class


"Classes, modules, and objects are interrelated. In the diagram that
follows, the arrows represent inheritance, and the parentheses
meta-classes. All metaclasses are instances of the class `Class'."

+------------------+
| |
Object---->(Object) |
^ ^ ^ ^ |
| | | | |
| | +-----+ +---------+ |
| | | | |
| +-----------+ | |
| | | | |
+------+ | Module--->(Module) |
| | ^ ^ |
OtherClass-->(OtherClass) | | |
| | |
Class---->(Class) |
^ |
| |
+----------------+



I do not see what's wrong here, can you explain?

definitive errors:

a) not all arrows represent inheritance, just the verticals.

b) the relation "(Object)"---[inherits from]--->"Class" is false.

correct: "(Object)"---[inherits-from]------->nil

As other people have pointed out this is wrong since nothing can inherit
from nil, since it isn't a class.

simply rephrase to:

"Object inherits from nothing" or

"Object does not inherit".

The mistake you're making is that (Object) doesn't represent an instance
of Object.

I understand.

Thus horizontal arrows represent inheritance, too.

Let's see.

It represents Object's metaclass.

again my initial question:

how do I access this metaclass?

Using _why's metaid library

this library is irrelevant.

I'm evaluating standard ruby and its Object Model.

The [Meta] Object Model must be accessible without additional libraries.

Object.metaclass.superclass #=> Class

output of pure ruby:

irb(main):014:0> Object.metaclass.superclass
NoMethodError: undefined method `metaclass' for Object:Class
from (irb):14

So the ruby documentation is correct, (Object) does inherit from Class

not in my installation:

I have no "(Object)"

or

correct: "(Object)"---[is-an-instance-of]--->Class

This is correct. (Object) both inherits from and is an instance of Class.

it's easier:

(Object) is not existent.

Object and (Object) are both classes.

"Object" and "(Object)" are essentially the same thing.

no there is a "class" and a (metaclass)

there are no metaclasses in ruby.

If i'm wrong:

please show me the pure-ruby [no additional libraries] access-code.

-

The version 1.1 UML diagramm backups all my statements.

You can verify it with a standard ruby installation:

http://lazaridis.com/case/lang/ruby/

..

 

[Jim Weirich]

Using _why's metaid library

this library is irrelevant.
I'm evaluating standard ruby and its Object Model.
The [Meta] Object Model must be accessible without additional libraries.

Accessing Object's metaclass:
=> Class

So, the metaclass of Object /does/ inherit from class.

Now we demonstrate that the object in meta_class_of_Object is really the
metaclass by defining a method on Object and finding the method added to its
metaclass:

meta_class_of_Object.instance_methods(false) => ["new", "allocate"]
def Object.method_only_in_Object(); puts "HI"; end => nil
meta_class_of_Object.instance_methods(false) => ["method_only_in_Object", "new", "allocate"]
Object.method_only_in_Object

HI
=> nil

 

[David A. Black]

Hi --

Using _why's metaid library

this library is irrelevant.
I'm evaluating standard ruby and its Object Model.
The [Meta] Object Model must be accessible without additional libraries.

Accessing Object's metaclass:
=> Class

So, the metaclass of Object /does/ inherit from class.

Doesn't that tell you that it is an instance of Class, rather than
that it inherits from Class? As opposed to:

irb(main):001:0> c = (class << Object; self; end)
=> #<Class:Object>
irb(main):002:0> c.superclass
=> Class

?


David

 

[Austin Ziegler]

"class Object inherits from nothing (represented by object nil)"

This is not true.

Object is the root object. It has no parents. It needs no parents. To
paraphrase:

In the beginning was the Object, and the Object was Object.

-austin

 

[Austin Ziegler]

Ilias Lazaridis wrote:
please do _not_ focus on the nil issue, but on the existing documentation.

this is covered for now with this statement:

"class Object inherits from nothing (represented by object nil)"

But, as stated, this is wrong.

Object doesn't inherit from nil or NilClass.

The existing diagram is far better than your attempt.

-austin

 

[Ilias Lazaridis]

Jim Weirich wrote:
[...] - (creating new context)

please, the context of the discussion is already given:

I've stated, that the _specific_ and _given_ (described within "ri
Class") "(Object)" metaclass is not existent.

launch irb.

"Object" is accessible.

please name me the "(Object)" class.

you cannot:

it's not existent.

..

 

[Martin DeMello]

please, the context of the discussion is already given:

I've stated, that the _specific_ and _given_ (described within "ri
Class") "(Object)" metaclass is not existent.

launch irb.

"Object" is accessible.

please name me the "(Object)" class.

you cannot:

it's not existent.

Ruby supports the concept of anonymous but reachable objects.

a = ["Hello", "world"]

The two strings in the array have no name other than a[0] and a[1], but
they certainly exist.

a.each {|i| puts i}

The block passed to a.each has no name at all, but it too exists.

Also, the ruby community recognises the value of documentation-level
abstractions and conventions.

String#reverse is not ruby syntax, but shorthand for "the instance
method 'reverse' of objects of class String", and it's a valuable and
widely understood convention in the documentation. Likewise, (Object) is
not ruby syntax, but shorthand for "the singleton class of the class
object Object", and is likewise valuable (try redrawing the diagram
using the expanded form) and understood.

martin

 

[Carlos]

not exactly, it's more a "becomes" relation:

"class definition" ----"becomes"----> "(class) instance"

(?) Please see (attempt to) explanation below. I got a bit enthused with the
ascii art, sorry, but it helped to my understanding of the issue, too.

"instance of" would be false, because:

* the direction fo the arrow would be wrong

Normally, the standard arrow goes from instance to class

person ----is an instance of the class---> Person

* all 'metaclasses' are instances of the class "Class"

Yes, the text says that to avoid drawing too many arrows.

Here is the explanation. Please bear with me and correct possible errors:

Objects have only data (instance variables). Their classes have methods.
When you write "person.say_hello", Ruby looks up the method "say_hello" in
the Person class, sets "self" to the object "person" and executes the
method. If you call a method not in the class Person, the method is looked
up in Person's superclass, and so on. We agree until here, yes?

[Object ]
^
|
[person ] ---- instance of ----> [Person ]
@name say_hello()

But now, you have a special person, who says hello differently. If you
change the method "say_hello()" in Person, *all* instances will use it. So
you insert a singleton class, only for the object "person":

[Object ]
^
|
[person ] ----- instance of ----> [Person ]
@name say_hello()
^
|
[mute ] ---- instance of ----> [(mute) ]
@name say_hello() (redefined only for
"mute")

Now, classes are objects, too, with the difference that they have methods
for their instances to use. So, when you call "Person.new", Ruby looks up
the method "new" in Person's class, which is "Class". Then it sets "self" to
the object "Person" and executes the method.

[Object ] [Module ]
^ ^
| |
[Person ] ---- instance of ----> [Class ]
new()

Now say that you want the class Person to have a new method, for example
"new_with_name()". You must define the method in its class, but if you
define it in "Class", *all* objects that are instances of class (that is,
all classes) will have that method. So you create a singleton class for
Person:

[Module ]
^
|
[Class ]
[Object ] new()
^ ^
| |
person -----> [Person ] ---- instance of ----> [(Person) ]
new_with_name()

We agree until now? "person.id()" will try to find "Person#id", then
"Object#id". "Person.attr_accessor" will try to find
"(Person)#attr_accessor", then "Class#attr_accessor", then
"Module#attr_accessor". First go to the right, then up until you find it.

Now let's say you create a new class "Man", inheriting from "Person". You
expect to be able to say "Man.new_with_name()", so the class of "Man"
shouldn't be "Class", but "(Person)". Well, let's assume that the singleton
class for "Man" is already created:

[Class ]
[Object ] new()
^ ^
| |
person -----> [Person ] ---- instance of ----> [(Person) ]
^ ^ new_with_name()
mute -> [(mute)] | ^
| |
man --------> [Man ] ---- instance of ----> [(Man) ]


Of course, the same logic applies to "Person". If "Object" has a singleton
class, we expect that "(Person)" inherits from it ("(Object)"). And also,
all these singleton classes (metaclasses) are instances of "Class". So let's
complete the diagram:

[Class ]
new()
^
|
[Object ] ---- instance of ----> [(Object) ] ---> [Class]
^ ^
| |
person -----> [Person ] ---- instance of ----> [(Person) ] ---> [Class]
^ ^ new_with_name()
mute -> [(mute)] | ^
| |
man --------> [Man ] ---- instance of ----> [(Man) ] ---> [Class]


Well, that's all. I can't squeeze out any more understanding of metaclasses
from my brain. In the upper stages things get a little mixed up, because
metaclasses are instances of Class, but also ultimately inherit from it, so
you need a diagram as the one in "ri Class" to sort these relationships out.
But I don't think that diagram is wrong at all.

Hope this helped. It helped me, at least.

class Person
class << self # now we are in class (Person)
def new_with_name name
o = new
o.name = name
o
end
end

def say_hello
puts "Hello"
end

attr_accessor :name
end

class Other
end

person = Person.new_with_name "Someone"
puts person.name
person.say_hello

mute = Person.new

class << mute # now we are in class (mute)
def say_hello
puts "..."
end
end

mute.say_hello

class Man < Person
end

fred = Man.new_with_name "Fred"
puts fred.name

other = Other.new_with_name "x"

 

[James Edward Gray II]

the new diagramm (needs possibly a refresh within your browser):

http://lazaridis.com/case/lang/ruby/

-

please do _not_ focus on the nil issue, but on the existing
documentation.

I wish I didn't have to but you have a clearly incorrect arrow and
label. This has been adequately proven by plenty of experts on this
list. The language designer himself has asked you to remove it. You
have become the problem you were complaining about: You are now
publishing false documentation.

You claim your "evaluation" is a service to the Ruby community.
However, making incorrect documentation easily accessible is just the
opposite. If someone learning Ruby stumbles upon your site and
believes what they read there, you have done both the individual and
the community a great disservice.

You are constantly proving a complete lack of all essential social
skills and I feel we're going above and beyond the call to ignore this
and find any possible value for your discussions. Worse, you display
the same void of essential programming skills, causing you to obsess
over minute language details and totally bypass helpful insights into
the language itself. This too we have gone to great lengths to
tolerate. Unfortunately, you've crossed the line from annoying to
dangerous.

I must now strongly encourage all people still learning Ruby to avoid
your information, as the results are likely outright incorrect and you
are proving yourself incapable of admitting that.

That's my evaluation of your evaluation.

James Edward Gray II

 

[Jim Weirich]

David A. Black said:

Doesn't that tell you that it is an instance of Class, rather than
that it inherits from Class? As opposed to:

irb(main):001:0> c = (class << Object; self; end)
=> #<Class:Object>
irb(main):002:0> c.superclass
=> Class

I stand corrected. David's code demonstrates that the metaclass does
inherit from Class. Mine demonstrated that it was an instance of Class.

 

[vruz]

[EVALUATION] - E03b - The Ruby Object Model

please re-tag as [ILIAS]

 

[Florian Groß]

"class Object inherits from nothing (represented by object nil)"

Not all nothings you can possibly think of are represented by 'nil'. One
example: If there is nothing in an Array that is not the same as [nil].

So there really is not much of a meaningful connection between Object
and NilClass. (That way -- NilClass inherits from Object, however)

 

[Jim Weirich]

Ilias Lazaridis said:

I've stated, that the _specific_ and _given_ (described within "ri
Class") "(Object)" metaclass is not existent.

launch irb.

"Object" is accessible.
please name me the "(Object)" class.
you cannot:
it's not existent.

The class has no "name". That means it is anonymous. It does not mean it
doesn't exist.

In the context of the diagram, the notation "(Object)" is used to denote
the metaclass of Object. This is not the name of the class (which has no
name). The class so designated does exist as demonstrated in the irb
session in the previous message.

 

[Florian Groß]

see my reply to Mr. Matsumoto:

"class Object inherits from nothing (represented by object nil)"

new diagramm:

http://lazaridis.com/case/lang/ruby/

Why is it so hard to say "doesn't inherit" instead of "inherits from
non-existent"? Expertise isn't making things looking more complex than
they are -- it is making them as simple as possible, but not any
simpler. Just remove clutter that doesn't matter and you will end up
with a diagram that is more clear and easier to understand.

I'm not sure what you mean by the term 'singleton instance' -- classes
are instances of Class. Whenever you see something like 'foobars' you
can transform that to 'instances of Foobar' mentally.

What Ruby's singleton classes do is providing a way of treating a single
Object as if it had a class by itself that nobody else uses. Here is an
example:

obj = "hello world"
def obj.reverse() "fake reverse" end
obj.reverse # => "fake reverse"
"foobar".reverse # => "raboof"

Which is equivalent to this:

obj = "hello world"
class << obj # enter singleton class
def reverse() "fake reverse" end
end # exit singleton class
obj.reverse # => "fake reverse"
"foobar".reverse # => "raboof"

And as you can see from this example singleton classes are indeed
handled as regular classes:

obj = "hello world"
class << obj
# outputs #<Class:#<String:0x2b83cc8>> (or similar)
p self
# outputs Class
p self.class
# outputs [String, Enumerable, Comparable, Object, Kernel]
p self.ancestors
attr_accessor :foo
end
obj.methods(false) # => ["foo", "foo="]

That is basically all you need to know about singleton classes. The rest
is implementation details.

If you really want to give Ruby a look and aren't just doing these
evaluations to waste your time / boost your curriculum vitae then that
information will help you. If not then you are probably happy about me
wasting my time by responding to you. I'm still not sure what your
intentions are, but I'd certainly like to believe that you are a honest
person, even though you had a bit of trouble with approaching various
communities before.

It is okay to ask questions about this relatively exotic parts of Ruby,
but please do research before asking -- that can mean reading a book
that is available online for free, buying a book and reading it in
commute time or just trying things out in IRB / a personal set of unit
tests.

 

[Florian Groß]

We agree until now? "person.id()" will try to find "Person#id", then
"Object#id". "Person.attr_accessor" will try to find
"(Person)#attr_accessor", then "Class#attr_accessor", then
"Module#attr_accessor". First go to the right, then up until you find it.

And Ruby describes (Person)#attr_accessor as Person.attr_accessor:

class Person; end
def Person.attr_accessor() end
Person.methodattr_accessor) # => #<Method: Person.attr_accessor>

Person.methodnew) # => #<Method: Class#new>

[].methodinject) # => #<Method: Array(Enumerable)#inject>

I think this notational difference helps in figuring out where a method
truly comes from.

I think your explanation was a good one, even though in practice you can
ignore the fact that meta classes are implemented by inserting the meta
class before the physical class in the inheritance chain and that an
object is thus an instance of its meta class.

 

[Lionel Thiry]

Ilias Lazaridis a écrit :

there are other ways of answering, too.

You're right!

Then change your way of asking, and I bet people will change their ways of
anwsering!

it's incomplete, wrong and missleading.

I may seem to ask a bit too much of you, but, would you mind explain where it is
wrong?

of course i ignore them.

they are not relevant when reviewing ruby's oject-model.

If you knew about singleton methods, the said metaclasses would not have been
such a source of confusion for you.

the seperation exist in reality (and in the "ri class" documentation).

additionally: It was neccessary for my understanding process.

the next version (1.1), the diagramm will be simplified (possibly in a
few hours, if the stuff has passed).



yes, but there is still a class definition.

In fact, not even. In java or C++, they are processed during compilation, not
during execution. In ruby, those "declarations" are really processed during
execution. So, they look like declarations, but they are not: they are
instructions. Hence I told you that separation in your UML diagram is a source
of confusion.

this is not relevant to understand ruby's Object Model.

But this would help you so much!

I just need a (correct) UML diagram to understand Ruby's Object Model.



you are wrong:

By the way, you should never say to someone "you are wrong". Prefer to say "If
you are right, then, I don't understand this". Doing things that way, you'd
avoid a lot of flaming.

irb(main):001:0> Object.superclass
=> nil
irb(main):002:0> nil.class
=> NilClass

irb(main):001:0> Object < nil.class
=> false
irb(main):002:0> Object > nil.class
=> true

 

[Lionel Thiry]

Ilias Lazaridis a écrit :

Using _why's metaid library

this library is irrelevant.

I'm evaluating standard ruby and its Object Model.

The [Meta] Object Model must be accessible without additional libraries.

Just check this page then:
<http://whytheluckystiff.net/articles/seeingMetaclassesClearly.html>

A little advice by the way. You should not say:

this library is irrelevant.

I'm evaluating standard ruby and its Object Model.

The [Meta] Object Model must be accessible without additional libraries.

which shows a great lack of tact,
but instead:

I'm evaluating standard ruby and its Object Model.

The [Meta] Object Model must be accessible without additional libraries.

Why would this metaid.rb be relevant for me?

which would be a bit better.

 

[Ilias Lazaridis]

(?) Please see (attempt to) explanation below. I got a bit enthused with the
ascii art, sorry, but it helped to my understanding of the issue, too.

[...] - (thorough elaboration)

I'm sorry, I cannot review this at this point.

[protection of own understanding process]

I have marked your message for a later review.

My apologies.

..