Where does this "global code" fit in?

[Glenn]

You'll excuse me, but I'm coming from a Visual Basic background and am
trying to give myself a good OO knowledge using Ruby (I just LOVE the
Ruby language, having failed miserably at Smalltalk!).

So this is a relatively simple OO question.

Supposing I have a simple ruby program containing just this code:


class Window
#some code here (assume a method "show" is defined somewhere)
end

w = Window.new #<<<
w.show #<<<


Now I understand that Ruby is pure-OOP. And I guess that class
"Window" is implicitly deriving from superclass Object.

It's the two lines at the end that confuse me. My natural though is
they are "global", but in a pure-OO world, they've got to fit into a
class somewhere? If so, are they actually fitting into (extending)
class "Object" in some way? Where? How?

Ta muchly

Glenn.

 

[Florian Gross]

class Window
#some code here (assume a method "show" is defined somewhere)
end

w = Window.new #<<<
w.show #<<<

It's the two lines at the end that confuse me. My natural though is
they are "global", but in a pure-OO world, they've got to fit into a
class somewhere? If so, are they actually fitting into (extending)
class "Object" in some way? Where? How?

In the Java world they would have to go into a Class. But Ruby is
expression based and more rational -- if you type in code at the top
level it will be executed in the context of a special regular Object
which is called 'main'. It's just a regular Object with a few custom
methods that are just defined for that particular Object (singleton
methods) -- note that it's a regular Object meaning it has the methods
in the Kernel class available to it as well!

Note that even the definitions of classes and everything else are
executed in that context. Ruby is consistent.

Here's the list of special methods the top-level Object has:

C:\dev.svn\ruby>ruby
puts methods(false).sort.map { |name| [name, method(name).inspect].join(": ") }
^Z
include: #<Method: main.include>
private: #<Method: main.private>
public: #<Method: main.public>
to_s: #<Method: main.to_s>

include is usually not defined for Objects, but only for Modules.
main.include is equivalent to doing Object.sendinclude, ...).

private and public are usually only for Modules as well, but if you
define a method at the top level it is defined in Kernel. So it does
make sense to be able to overwrite the visibility of these as well.
Default visibility at the top level is private, for Modules it defaults
to public.

main.to_s just returns 'main'.

Hope this was of help.

 

[Glenn]

Excellent Florian, many thanks!

class Window
#some code here (assume a method "show" is defined somewhere)
end

w = Window.new #<<<
w.show #<<<

It's the two lines at the end that confuse me. My natural though is
they are "global", but in a pure-OO world, they've got to fit into a
class somewhere? If so, are they actually fitting into (extending)
class "Object" in some way? Where? How?

In the Java world they would have to go into a Class. But Ruby is
expression based and more rational -- if you type in code at the top
level it will be executed in the context of a special regular Object
which is called 'main'. It's just a regular Object with a few custom
methods that are just defined for that particular Object (singleton
methods) -- note that it's a regular Object meaning it has the methods
in the Kernel class available to it as well!

Note that even the definitions of classes and everything else are
executed in that context. Ruby is consistent.

Here's the list of special methods the top-level Object has:

C:\dev.svn\ruby>ruby
puts methods(false).sort.map { |name| [name, method(name).inspect].join(": ") }
^Z
include: #<Method: main.include>
private: #<Method: main.private>
public: #<Method: main.public>
to_s: #<Method: main.to_s>

include is usually not defined for Objects, but only for Modules.
main.include is equivalent to doing Object.sendinclude, ...).

private and public are usually only for Modules as well, but if you
define a method at the top level it is defined in Kernel. So it does
make sense to be able to overwrite the visibility of these as well.
Default visibility at the top level is private, for Modules it defaults
to public.

main.to_s just returns 'main'.

Hope this was of help.

 

[Mathieu Bouchard]

Now I understand that Ruby is pure-OOP. And I guess that class
"Window" is implicitly deriving from superclass Object.
It's the two lines at the end that confuse me. My natural though is
they are "global", but in a pure-OO world, they've got to fit into a
class somewhere? If so, are they actually fitting into (extending)
class "Object" in some way? Where? How?

Don't be confused by how Java redefines pure-OOP (Java has too much
influence on people's vocabulary and expectations). What pure-OOP is,
outside of the Java bubble, is not that all code is in classes, but rather
that all data is in objects.

Some things in Ruby, like @-variables, aren't objects themselves, but are
still sub-parts of objects. Some other things are not objects at all nor
clearly part of objects, but there are few of them, and still the spirit
of the language is to have most everything revolve around objects.

The purest-OOP languages might be Self and Beta, both of which
simplify/unify concepts to a degree that other language designers aren't
daring to. Just below that extreme level you find Ruby and Smalltalk. A
lower level of purity are languages in which OOP was retrofitted but
deeply so (C++,Perl). A very low level of purity is languages in which OOP
was designed in but instead feel like OOP has been badly retrofitted (in
Java, compare float and Float, and how different they are, and how this
breaks a sense of togetherness and consistency)

_____________________________________________________________________
Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju

 

[Robert Klemme]

Don't be confused by how Java redefines pure-OOP (Java has too much
influence on people's vocabulary and expectations). What pure-OOP is,
outside of the Java bubble, is not that all code is in classes, but rather
that all data is in objects.

I would even go so far as to say that there is no common understanding of
the term "pure OOP" like there is not commonly agreed understanding of OO
in general. At least, that's my impression from what I read in varous
places.

Some things in Ruby, like @-variables, aren't objects themselves, but are
still sub-parts of objects. Some other things are not objects at all nor
clearly part of objects,

What exactly do you mean here, global variables?

but there are few of them, and still the spirit
of the language is to have most everything revolve around objects.
Definitely.

The purest-OOP languages might be Self and Beta, both of which
simplify/unify concepts to a degree that other language designers aren't
daring to. Just below that extreme level you find Ruby and Smalltalk. A
lower level of purity are languages in which OOP was retrofitted but
deeply so (C++,Perl).

Deeply in Perl? I definitely object to that statement if it was supposed
to mean tight integration. If it means that it shows up all over the
place in the implementation of the perl interpreter then it might be true.
I can't comment on that as I don't have insights there.

A very low level of purity is languages in which OOP
was designed in but instead feel like OOP has been badly retrofitted (in
Java, compare float and Float, and how different they are, and how this
breaks a sense of togetherness and consistency)

That was deliberately done for performance reasons. Still Java OO is much
better than C++ and especially Perl IMHO. (I leave the arguments out,
because this is a topic of heated debate which is highly influenced by a
lot of personal taste. IOW: I don't easy agreement on this. )

Kind regards

robert