From: Mark Hubbart <discordantus@...>
Date: 2005-01-27T18:04:40+09:00
Subject: Re: top-level object? top-level methods?

On Wed, 26 Jan 2005 12:50:48 +0900, itsme213 <itsme213@hotmail.com> wrote:
> 
> "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 :-) 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