From: itsme213 <itsme213@...>
Date: 2005-01-26T12:50:48+09:00
Subject: Re: top-level object? top-level methods?


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

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