Top-level object? top-level methods?

ruby-talk
1

Is there a top-level object in any executing Ruby program? Is it the thing
called 'main' in irb?

Is so, why are top-level methods not made singleton-methods on this object,
instead of being pulled in as instance methods on the Object class itself
(and hence into all other classes i.e. more namespace pollution than is
usually intended). This would still allow top-level methods to call other
top-level methods. And if the top-level object were referred to by some
constant like Main, then those methods could be called from anywhere with
Main.method(...).

2

Hi,

Is there a top-level object in any executing Ruby program? Is it the thing
called 'main' in irb?

Yes and yes.

Is so, why are top-level methods not made singleton-methods on this object,
instead of being pulled in as instance methods on the Object class itself
(and hence into all other classes i.e. more namespace pollution than is
usually intended). This would still allow top-level methods to call other
top-level methods. And if the top-level object were referred to by some
constant like Main, then those methods could be called from anywhere with
Main.method(...).

Do you really wish to type "Main.print" everywhere?

              matz.

···

In message "Re: top-level object? top-level methods?" on Tue, 25 Jan 2005 12:30:50 +0900, "itsme213" <itsme213@hotmail.com> writes:

3

* If you are in an interactive session, or create a 10-line script to
parse stdin which looks like sanitized perl, you don't care about
namespace pollution.

* If you write a "proper" ruby program, you encapsulate your code into
Classes/Modules anyway.

So I think the toplevel namespace pollution is not an issue...

Csaba

···

On 2005-01-25, itsme213 <itsme213@hotmail.com> wrote:

Is so, why are top-level methods not made singleton-methods on this object,
instead of being pulled in as instance methods on the Object class itself
(and hence into all other classes i.e. more namespace pollution than is
usually intended). This would still allow top-level methods to call other
top-level methods. And if the top-level object were referred to by some
constant like Main, then those methods could be called from anywhere with
Main.method(...).

4

Shouldn't #print really be in a module somewhere and then included
when I want to be able to "print"..?

M

···

On Tue, 25 Jan 2005 17:26:29 +0900, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:

>Is so, why are top-level methods not made singleton-methods on this object,
>instead of being pulled in as instance methods on the Object class itself
>(and hence into all other classes i.e. more namespace pollution than is
>usually intended). This would still allow top-level methods to call other
>top-level methods. And if the top-level object were referred to by some
>constant like Main, then those methods could be called from anywhere with
>Main.method(...).

Do you really wish to type "Main.print" everywhere?

--
Matt Mower :: http://matt.blogs.it/

5

Shouldn't #print really be in a module somewhere and then included
when I want to be able to "print"..?

Well, in this case do you want to always write

  Main.require, Main.exit, Main.eval, Main.proc, ...

Guy Decoux

6

Maybe I've gotten the wrong end of the stick about the original question.

require 'pp'

I can then refer to 'pp' without prefixing. I'm not clear why print
(and much of the other stuff globbed into Object) should be any
different since it arguably clutters the namespace.

A require 'convenience' could, imo, emulate the current situation
without requiring the clutter.

But, as I say, perhaps I didn't grasp the original point.

M

···

On Tue, 25 Jan 2005 19:53:18 +0900, ts <decoux@moulon.inra.fr> wrote:

> Shouldn't #print really be in a module somewhere and then included
> when I want to be able to "print"..?

Well, in this case do you want to always write

  Main.require, Main.exit, Main.eval, Main.proc, ...

From my perspective, if I
--
Matt Mower :: http://matt.blogs.it/

7

A require 'convenience' could, imo, emulate the current situation
without requiring the clutter.

It occurs to me that, as well as being a bad pun, this isn't clear.
What I meant was you could add all the convenience methods using a
"convenience" module which could be required when necessary. This
module in turn might require other, fine grained, modules where
independent functionalities like "print" could live.

I guess, philosophically, I'm of the Ruby Facets mindset. I'd rather
have smaller, finegrained, functionalities that could be bound in when
I need them (as long as it's still convenient when I do, and I think
that it is).

Regards,

Matt

···

--
Matt Mower :: http://matt.blogs.it/

8

require 'pp'

Hey, you can't write this :slight_smile:

You must write

  Main.require 'pp'

Guy Decoux

9

Hi Guy,

···

On Tue, 25 Jan 2005 20:09:14 +0900, ts <decoux@moulon.inra.fr> wrote:

> require 'pp'

Hey, you can't write this :slight_smile:

You must write

  Main.require 'pp'

Well I did say "much" of the stuff in object, not all :wink:

M
--
Matt Mower :: http://matt.blogs.it/

10

ts schrieb:

"M" == Matt Mower <matt.mower@gmail.com> writes:

> require 'pp'

Hey, you can't write this :slight_smile:

You must write

  Main.require 'pp'

I think the original poster asked why

   def do_something
     p "hi"
   end

becomes a private method of Object instead of a singleton method of a top-level object/module called "Main". He didn't want to prefix all Object/Kernel methods with Main.

Why should, after the definition above, the following be legal as it is today:

   Time.send :do_something # => "hi"

("Time" is just an example. You can substitute any other object.)

The suggested behavior would be

   Time.send :do_something # => NoMethodError

   Main.do_something # => "hi"

I like this proposal. Would there be any drawbacks?

Regards,
Pit

11

Hi,

···

In message "Re: top-level object? top-level methods?" on Wed, 26 Jan 2005 00:07:19 +0900, Pit Capitain <pit@capitain.de> writes:

I like this proposal. Would there be any drawbacks?

1. Compatibility. It would break a lot of code, which assume
   top-level def can be seen from everywhere.

2. Mindset. I feel above assumption is natural.

              matz.

12

"Yukihiro Matsumoto" <matz@ruby-lang.org> wrote in message

Hi,

>I like this proposal. Would there be any drawbacks?

1. Compatibility. It would break a lot of code, which assume
   top-level def can be seen from everywhere.

A compatibility mode perhaps :slight_smile:

class Object
    def method_missing sym, *args, &block
        if Main.respond_to? sym
            Main.send sym, *args, &block
        else normal_method_missing_stuff
    end
end

2. Mindset. I feel above assumption is natural.

With the option of using modules and includes, I am not sure the namespace
pollution is worth it. I do fully agree with one of the original goals of
making procedural programmers quite at home, and don't think this approach
would sacrifice that goal.

I find myself throwing in top-level methods when in a rush, when it is
convenient, I don't need multiple instances, etc. But I don't think I ever
throw them in with the _intent_ of calling them from anywhere. Of course,
because they are currently callable from anywhere, code will end up using it
that way.

···

In message "Re: top-level object? top-level methods?" > on Wed, 26 Jan 2005 00:07:19 +0900, Pit Capitain <pit@capitain.de> writes:

13

Yukihiro Matsumoto schrieb:

···

    on Wed, 26 Jan 2005 00:07:19 +0900, Pit Capitain <pit@capitain.de> writes:

>I like this proposal. Would there be any drawbacks?

1. Compatibility. It would break a lot of code, which assume
   top-level def can be seen from everywhere.

2. Mindset. I feel above assumption is natural.

Oh, now I see. Seems I've never mixed procedural and OO code, so I hadn't thought of any use for this "feature". Thanks for the clarification. I should have known you chose this implementation for a reason.

Regards,
Pit

14

"Yukihiro Matsumoto" <matz@ruby-lang.org> wrote in message

Hi,

>I like this proposal. Would there be any drawbacks?

1. Compatibility. It would break a lot of code, which assume
   top-level def can be seen from everywhere.

A compatibility mode perhaps :slight_smile: Don't know is something like this is a good
idea, but ...

class Object
    def method_missing sym, *args, &block
        if Main.respond_to? sym
            Main.send sym, *args, &block
        else normal_method_missing_stuff
    end
end

Old code that relied on main methods being in Object should still run (I
think, have not tested). New code that relies on main methods being in Main
will still run, except for certain #method_missing cases that made it all
the way up to Object. Sounds ok to me.

2. Mindset. I feel above assumption is natural.

I fully agree with the goal of making procedural programmers at ease. This
approach does not sacrifice that goal. But it does affect existing OO +
procedural code, hence a compatibility mode for this change? Someone
knowingly combining OO and procedural code can always use modules and
includes if they need to approximate the old behavior. So I am not sure the
namespace pollution is worth it.

I typically throw in top-level methods for short scripts, when in a rush,
when it is convenient, I don't need multiple instances, or just being sloppy
etc. But I don't think I ever throw them in with the _intent_ of calling
them from anywhere. Of course, because they are currently callable from
anywhere, code will end up using it that way.

···

In message "Re: top-level object? top-level methods?" > on Wed, 26 Jan 2005 00:07:19 +0900, Pit Capitain <pit@capitain.de> writes:

15

"Yukihiro Matsumoto" <matz@ruby-lang.org> wrote in message
> Hi,
>
>
> >I like this proposal. Would there be any drawbacks?
>
> 1. Compatibility. It would break a lot of code, which assume
> top-level def can be seen from everywhere.

A compatibility mode perhaps :slight_smile: Don't know is something like this is a good
idea, but ...

class Object
    def method_missing sym, *args, &block
        if Main.respond_to? sym
            Main.send sym, *args, &block
        else normal_method_missing_stuff
    end
end

Old code that relied on main methods being in Object should still run (I
think, have not tested). New code that relies on main methods being in Main
will still run, except for certain #method_missing cases that made it all
the way up to Object. Sounds ok to me.

It already behaves this way, except for the lack of the Main object.

def read
  puts "Once upon a time..."
end
    ==>nil
Object.new.send(:read)
Once upon a time...
    ==>nil
File.new("/etc/hosts").send(:read)
    ==>"##\n# Host Database\n#\n# localhost is used to configure the
loopback interface\n# when the system is booting. Do not change this
entry.\n##\n127.0.0.1\tlocalhost\n255.255.255.255\tbroadcasthost\n::1
           localhost \n\n"

> 2. Mindset. I feel above assumption is natural.

I fully agree with the goal of making procedural programmers at ease. This
approach does not sacrifice that goal. But it does affect existing OO +
procedural code, hence a compatibility mode for this change? Someone
knowingly combining OO and procedural code can always use modules and
includes if they need to approximate the old behavior. So I am not sure the
namespace pollution is worth it.

I typically throw in top-level methods for short scripts, when in a rush,
when it is convenient, I don't need multiple instances, or just being sloppy
etc. But I don't think I ever throw them in with the _intent_ of calling
them from anywhere. Of course, because they are currently callable from
anywhere, code will end up using it that way.

I'm not sure what the problem is. Top level def methods are private,
so they don't affect #respond_to?. Methods of the same name defined in
Object's subclasses will mask those messages. When you talk about
polluting, it makes it sound like they get in the way, and cause all
manner of problems; I don't see how this could be possible. Is there a
reason for changing it, other than to make Ruby more pure?

I'm not trying to give the idea the smackdown, but since I only see a
semantic difference between the two ways of doing it, I feel that
pollution is perhaps a bit too strong a word.

cheers,
Mark

···

On Wed, 26 Jan 2005 12:50:48 +0900, itsme213 <itsme213@hotmail.com> wrote:

> In message "Re: top-level object? top-level methods?" > > on Wed, 26 Jan 2005 00:07:19 +0900, Pit Capitain <pit@capitain.de> > writes:

16

It was just a couple of days back that I commented on a post
(http://www.livejournal.com/users/premshree/39574.html\) in Live
journal where I said that Ruby is so cool because it is completely
object-oriented, yet allows for procedural programming.
+1 for keeping things as they are.

What does a top-level object mean anyway? I never understood that. If
someone would care to explain........ ( C++, Java background here)

Thank you,
Gavri

···

On Wed, 26 Jan 2005 12:50:48 +0900, itsme213 <itsme213@hotmail.com> wrote:

I fully agree with the goal of making procedural programmers at ease. This
approach does not sacrifice that goal. But it does affect existing OO +
procedural code, hence a compatibility mode for this change? Someone
knowingly combining OO and procedural code can always use modules and
includes if they need to approximate the old behavior. So I am not sure the
namespace pollution is worth it.

17

I'm not sure what the problem is. Top level def methods are private,
so they don't affect #respond_to?. Methods of the same name defined in
Object's subclasses will mask those messages. When you talk about
polluting, it makes it sound like they get in the way, and cause all
manner of problems; I don't see how this could be possible. Is there a
reason for changing it, other than to make Ruby more pure?

I'm not trying to give the idea the smackdown, but since I only see a
semantic difference between the two ways of doing it, I feel that
pollution is perhaps a bit too strong a word.

+1.

Don't break it -- not all problems are OO-shaped, no need to make ruby
less suitable for programs that aren't OO.

Besides, all the one-liners and such (which I write every day) rely on
this: it's a feature, not a bug.