On Oct 22, 3:36 ¨Âí¬ Éîôòáîóéôéïî ¼ôòáîóæ®®®Àçíáéì®ãïí÷òïôåº
> On Oct 22, 2:55 ¨Âí¬ Êïèî Íáéò ¼êòí®®®Àçíáéì®ãïí¾ ÷òïôåº
>
>
>
> > Thomas Sawyer wrote in post #956386:
>
> > > On Oct 22, 5:51 am, John Mair <jrm... / gmail.com> wrote:
> > >> Why is it that top-level isn't just the Object class itself? what's the
> > >> rationale behind the 'main' object?
>
> > > It should not be. In fact, I think it is a mistake for main to
> > > delegate to Object at all. It becomes a headache when trying to write
> > > a scripting DSL. Rather than run the script at toplevel --which is
> > > very nice b/c of the way #require works, one has to run the script in
> > > a evaluation context so as to prevent pollution of every object. It is
> > > easy enough to extend the Object class by opening it up or opening the
> > > Kernel module, so this delegation is little more than a "nicety" --but
> > > not a very nice one really.
>
> > > Ideally main would simply be:
>
> > > module Main
> > > extend self
> > > end
>
> > I can kinda buy that argument, though i can see some problems with it
> > too. Like what would the semantics of 'class Hello' be at top-level
> > then? You'd obviously want it to define a constant on Object or else
> > you'd have to reference Main to get it out. But if you did have the
> > syntax 'class Hello' define a constant on Object then how would you nest
> > class/module constants conveniently? etc. I do kinda like your idea
> > though i just see some difficulties.
>
> Constant lookup would have to be adjusted to go through Object and
> then on to Main.
>
> > Nonetheless, back to the original point (if you're interested in
> > commenting on it.) Assuming top-level does maintain its current
> > behaviour, can you see any strong reasons why not to just replace 'main'
> > with Object? since 'main' as been patched and hacked up to act mostly
> > like Object anyway (by messing with cref and default definee and giving
> > it a bunch of class-like singleton methods), what would be the problem
> > in just having the top-level context being Object itself? (forgetting
> > for a minute your objections, but concentrating instead on replicating
> > the current behaviour but with a more elegant model)
>
> It still has to differ at least slightly in that top-level methods
> have to be private Object methods.
>
> Also, top-level instance could cause also sorts of messy:
>
> class X
> def initialize(a)
> @a = a
> end
> def to_s; @a.to_s; end
> end
>
> class Y
> def initialize(a)
> @a = a
> end
> def to_s; @a.to_s; end
> end
>
> x = Y.new(10)
> y = Y.new(20)
>
> puts x => "10"
> puts y => "20"
>
> @a = 30
>
> puts x => "30"
> puts y => "30"

My bad, that's not quite right. The @a would be at the class level,
so:

   class X
     def self.to_s
       @a ||= 10
     end
   end

   class Y
     def self.to_s
       @a ||= 20
     end
   end

   puts X  #=> "10"
   puts Y  #=> "20"

   @a = 30

   puts X  #=> "30"
   puts Y  #=> "30"