On Oct 22, 3:36=A0pm, Intransition <transf... / gmail.com> wrote:
> On Oct 22, 2:55=A0pm, John Mair <jrm... / gmail.com> wrote:
>
>
>
> > 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 i=
s
> > > easy enough to extend the Object class by opening it up or opening th=
e
> > > Kernel module, so this delegation is little more than a "nicety" --bu=
t
> > > not a very nice one really.
>
> > > Ideally main would simply be:
>
> > > =A0 module Main
> > > =A0 =A0 extend self
> > > =A0 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 nes=
t
> > 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:
>
> =A0 class X
> =A0 =A0 def initialize(a)
> =A0 =A0 =A0 @a =3D a
> =A0 =A0 end
> =A0 =A0 def to_s; @a.to_s; end
> =A0 end
>
> =A0 class Y
> =A0 =A0 def initialize(a)
> =A0 =A0 =A0 @a =3D a
> =A0 =A0 end
> =A0 =A0 def to_s; @a.to_s; end
> =A0 end
>
> =A0 x =3D Y.new(10)
> =A0 y =3D Y.new(20)
>
> =A0 puts x =A0#=3D> "10"
> =A0 puts y =A0#=3D> "20"
>
> =A0 @a =3D 30
>
> =A0 puts x =A0#=3D> "30"
> =A0 puts y =A0#=3D> "30"

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

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

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

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

   @a =3D 30

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