Rick Denatale wrote in post #956368: > On Fri, Oct 22, 2010 at 11:07 AM, John Mair <jrmair / gmail.com> wrote: >> But, for most cases main already behaves like Object: >> >> * calling 'include' in main actually includes in Object >> * defining a method in main actually defines the method on Object >> * defining a constant in main actually defines the constant on Object > > I think there's some confusion here between self and the current > class, and also about the differences in the relationship between > classes and instances between Ruby and many other "OO" languages. > There is no confusion. I am aware that the 'default definee' (current class) at top-level is Object and that this is different to the self at top-level which is main. > At the top level self refers to the top level object. I know. > The current class is a separate value in the state of the ruby > interpreter/vm which determines which class or module statements like > def and include operate on. You're only half-right here. Default definee determines what 'def' works on, but not include. At top-level 'include' is actually a singleton method on main (see method(:include).owner) and its definition is top_include() in eval.c where it explictly includes the module into Object (did you read the blog post i linked earlier...?) > At the top level the current class is > Object, and methods get defined as private by default. This makes > them LOOK like functions rather than methods. Ok. But i'm not debating this. :) >> The only notable exception, where 'main' acts like itself (that is - as >> an instance of Object) -- is instance variables. main has its own >> instance variables independent of Object. >> >> But i do not see a good reason not to just define the ivars on Object. >> >> See this post: >> http://banisterfiend.wordpress.com/2010/10/22/what-is-the-ruby-top-level/ > > And here is another difference between Ruby and languages you might be > "coming from." Instance variables are NOT "defined on" a class, but > are rather dynamically attached to instances as methods run. > I don't know what you mean here. I was talking about the ivars on Object - the *class* called Object. Classes can have ivars too, as im sure you're aware: e.g: class Hello @x = 10 end And these ivars ARE defined on an iv_tbl in the class (or at least on the rb_classext_t member in the class). I think we have been mainly talking at cross-purposes here. I do not disagree with a lot of what you have said but I also do not see how it is relevant. The point I was making was that: (1) 'current class' and 'cref' at top-level are Object anyway, so methods and constants will end up on Object. (2) the top-level include method, although it is defined on main (singleton class) actually includes into Object. Same with top-level public and private methods. (3) Instance variables, in so far as they're used (which i cant see what for, really) may as well just be defined on the Object class (i mean class instance variables here) So i thknk if you just made Object the top-level context rather than 'main' you would get (1) and (2) for free (wouldn't' have to define any weird singleton methods a la 'include') and (3) you may as put the ivars on Object class, ii can't really see any reason why not to :) John > http://talklikeaduck.denhaven2.com/2008/02/08/whose-variable-is-it-anyway > > -- > Rick DeNatale > > Help fund my talk at Ruby Conf 2010:http://pledgie.com/campaigns/13677 > Blog: http://talklikeaduck.denhaven2.com/ > Github: http://github.com/rubyredrick > Twitter: @RickDeNatale > WWR: http://www.workingwithrails.com/person/9021-rick-denatale > LinkedIn: http://www.linkedin.com/in/rickdenatale -- Posted via http://www.ruby-forum.com/.