Asp Forum - top-level object? top-level methods?

Its Me

1/25/2005 3:29:00 AM

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(...).

16 Answers

Yukihiro Matsumoto

1/25/2005 8:26:00 AM

Hi,

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

|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.

Matt Mower

1/25/2005 10:47:00 AM

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?
>

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

M

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

ts

1/25/2005 10:53:00 AM

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

M> Shouldn't #print really be in a module somewhere and then included
M> 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

Matt Mower

1/25/2005 11:06:00 AM

On Tue, 25 Jan 2005 19:53:18 +0900, ts <decoux@moulon.inra.fr> wrote:
> >>>>> "M" == Matt Mower <matt.mower@gmail.com > writes:
>
> M> Shouldn't #print really be in a module somewhere and then included
> M> 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, ...
>

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

From my perspective, if I

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

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

Matt Mower

1/25/2005 11:09:00 AM

> 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...

ts

1/25/2005 11:09:00 AM

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

M> require 'pp'

Hey, you can't write this :-)

You must write

Main.require 'pp'

Guy Decoux

Matt Mower

1/25/2005 11:19:00 AM

Hi Guy,

On Tue, 25 Jan 2005 20:09:14 +0900, ts <decoux@moulon.inra.fr> wrote:
> >>>>> "M" == Matt Mower <matt.mower@gmail.com > writes:
>
> M> require 'pp'
>
> Hey, you can't write this :-)
>
> You must write
>
> Main.require 'pp'
>

Well I did say "much" of the stuff in object, not all ;-)

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

Pit Capitain

1/25/2005 3:07:00 PM

ts schrieb:
>>>>>>"M" == Matt Mower <matt.mower@gmail.com> writes:
> M> require 'pp'
>
> Hey, you can't write this :-)
>
> 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

Yukihiro Matsumoto

1/25/2005 4:25:00 PM

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.

Its Me

1/25/2005 5:10:00 PM

"Yukihiro Matsumoto" <matz@ruby-lang.org> wrote in message
> 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.

A compatibility mode perhaps :-)

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.

comp.lang.ruby

top-level object? top-level methods?

Its Me

Yukihiro Matsumoto

Matt Mower

ts

Matt Mower

Matt Mower

ts

Matt Mower

Pit Capitain

Yukihiro Matsumoto

Its Me

x Login to ForumsZone