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