[ruby-core:45774] [ruby-trunk - Feature #6609] Toplevel as self extended module

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


=begin

> These aren't delegated, they are singleton methods which add behavior to make top-self more useful.

  static VALUE
  top_include(int argc, VALUE *argv, VALUE self)
  {
    rb_thread_t *th = GET_THREAD();

    rb_secure(4);
    if (th->top_wrapper) {
	rb_warning
	    ("main#include in the wrapped load is effective only in wrapper module");
	return rb_mod_include(argc, argv, th->top_wrapper);
    }
    return rb_mod_include(argc, argv, rb_cObject);
  }

Also, #define_method would make top level more useful too.

> No, due to what you said above ("how Ruby handles def in other defs").  Also:
>
>  ruby -e 'class C; def make; define_method(:foo) { } end; end; C.new.make'

No? This only serves to demonstrate the oddity. `def` and `define_method` aren't resulting in the same thing here. How is that what one would expect in the least? It's not, and this is something that one has to commit to memorization b/c it is not intuitive. But this proposal is also not about def. I understand it explains why top-level ends up a method of Object class, but this proposal seeks to end that regardless of def's behavior.

> The current behavior is bad for some things and good for others.

What is it good for?

> Also, since the top-self is one of the first objects new rubyists interact with, changing the behavior of top-self
> may break introductory tutorials on ruby.  Many, many people use it so we must be very careful when changing it.

Don't think it will break any such tutorials. This proposal should be compatible it every respect that counts. If a tutorial is teaching new rubyists to define top-level methods so they can be called upon any object, that's not a good tutorial.

But of course I agree, we have to be careful about such changes. I have considered this idea for many years and have asked many times over those years if it had any show-stopper issues that would make it not feasible. No one's come forward with any, so I think it's worth more serious consideration at this time.

> It is easy to create a clean-room DSL evaluation context now:

Yes, I have done this a number of times. It's actually not quite that simple or convenient. The ability to load/require into toplevel makes repurpose of top level for DSL very attractive. Using instance eval in subcontext also presents constant lookup issues.

> So the improvement is a convenience for a very rare use at the expense of a change every rubyist needs to learn about.

I think it would be used more than you might think. I have at least two programs I can think of off the top of my head where I could use this. Whereas the current behavior is of no beneficial use at all and seems to me really only serves to create bad code.

I realize this proposal entails a bit of reorientation with the idea of what the top level object *is*, especially for someone like yourself who is familiar with the underlying implementation. But I think if you step back and think about what how we conceive of the top level already -- as a "namespace", then this proposal really starts to take shape. 

Rather then something every rubyist needs to learn, it would bring Ruby up to what most Rubyists would generally expect.
=end
----------------------------------------
Feature #6609: Toplevel as self extended module
https://bugs.ruby-lang.org/issues/6609#change-27353

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/