Issue #6609 has been updated by trans (Thomas Sawyer).


> There are no method calls on the top-level object in this example. Nothing is delegated.

I've been able to find the code for three methods which delegate:

eval.c:      rb_define_singleton_method(rb_vm_top_self(), "include", top_include, -1);
vm_method.c: rb_define_singleton_method(rb_vm_top_self(), "public", top_public, -1);
vm_method.c: rb_define_singleton_method(rb_vm_top_self(), "private", top_private, -1);

I understand what you are saying about def now, b/c of how Ruby handles def in other defs. Actually, I always thought that was little odd. I know others have suggested that maybe inner defs should be local to the method itself. Not that it's a big deal --I think that's very minor thing. But now I see how one oddity became the result of another.

> Again, define_method only exists on Module and its subclasses.

If one is able to use `def` in a context, does in not stand to reason that one could also use `define_method`? Since #define_method is, after all, the means given us to create methods dynamically (without resorting to eval).

> That people have done bad things is not a compelling reason.

That is but *one* (good) reason. In fact, have you considered the other merits I mentioned? Arguing against this solely on the basis that the top-level is what the top-level is, pretty much misses the point to *improve* upon what it is.


P.S. In the course of working on this I may have come across an issue with irb. Looks like it is making top-level methods public methods of Object instead of private.


----------------------------------------
Feature #6609: Toplevel as self extended module
https://bugs.ruby-lang.org/issues/6609#change-27345

Author: trans (Thomas Sawyer)
Status: Open
Priority: Normal
Assignee: 
Category: core
Target version: 2.0.0


As promised sometime back here is my proposal that Toplevel object become a self-extended module instead of the current partial Object class proxy.

I have written about it in a blog post: http://trans.github.com/2012/06/17/kill-the-proxy-and-save-toplevel.html

In summary the basic idea is to have a special toplevel namespace that is self-extended, e.g.

  module Toplevel
    extend self
  end

in which all toplevel code is evaluated. 

Definitions at the toplevel would no longer inject into Object class. This frees up the toplevel to be used for general purpose DSL "batch" scripting. What I mean by that is that one can create a DSL, load it in to toplevel and then evaluate scripts based on it simply by load/require and without fret that the code loaded in will infect Object if it defines it's own methods.

Conceptually the idea of self-extended module is much simpler than current proxy object --there is really nothing special to understand about it since it is just a module like any other module.

With regard to backward compatibility, the only programs that would be effected are any that defined a toplevel method fully expecting it to add a method to Object. But those will be very rare since it is generally considered bad form to do that. (And of course the simple fix is to wrap the method in the proper `class Object private ... end` code.



-- 
http://bugs.ruby-lang.org/