[ruby-core:25888] Re: struggling to convince myself 1.9's constant lookup rules make any sense

On Oct 1, 8:47=A0am, "David A. Black" <[e-mail]> wrote:
> Hi --
>
>
>
>
> First thought: because the purpose of the rule, I think, is to clarify
> that there's a distinction, and the cost of that clarification is that
> it's a mistake not to make the distinction.
>
> For example:
>
> class C
> =A0 =A0def self.run(&block)
> =A0 =A0 =A0class_eval(&block)
> =A0 =A0end
> end
>
> class D
> =A0 =A0MyConst =3D 1
> =A0 =A0C.run { p MyConst }
> end
>
> That code will give you "unknown constant C::MyConst" in 1.9. The
> reasoning, as I understand it, is that the caller cannot depend one
> way or the other on whether there's a constant called MyConst in the
> evaluating class. In other words, there could be:
>
> =A0 =A0class C
> =A0 =A0 =A0MyConst =3D 2
>
> etc., in which case the call from D would not use D::MyConst -- so
> since D has no jurisdiction over whether C::MyConst exists, the only
> consistent approach is to assume that C will *always* have the
> responsibility for resolving MyConst.
>


hrm.  i don't really see it that way, at least it seems directly
opposed to how this runs, which prints '1' in both 1.8 and 1.9

cfp:~ > cat a.rb
class C
  def C.run(&block) class_eval(&block) end
  def C.myConst() 2 end
end

class D
  myConst =3D 1
  C.run { p myConst }
end

cfp:~ > ruby18 a.rb
1

cfp:~ > ruby19 a.rb
1


here the rule is *clearly* that the closure's scope comes before the
caller's scope.  but not that it is *not* an exclusive scope - a
failure to to a lookup on the closure the falls to the caller:

cfp:~ > cat a.rb
class C
  def C.run(&block) class_eval(&block) end
  def C.myConst() 2 end
end

class D
  C.run { p myConst }
end

cfp:~ > ruby18 a.rb
2

cfp:~ > ruby19 a.rb
2


my proposal is that const look up could work this way:

cfp:~ > cat a.rb
class C
  def C.run(&block)
    with_scope(block){ class_eval(&block) }
  end

  def C.with_scope(scope, &block)
    @scope =3D scope
    block.call
  ensure
    @scope =3D nil
  end

  def C.const_missing(const)
    @scope ? eval(const, @scope.binding) : super
  end
end

class D
  MyConst =3D 42
  C.run { p MyConst }
end


cfp:~ > ruby18 a.rb
42

cfp:~ > ruby19 a.rb
42


that is to say "prefer the caller but fall back to the closure."
that seems very POLS, for definitions of POLS that involve
'I'=3D=3Dara.t.howard ;-)


> It reminds me (maybe not one-to-one, but generally) of the
> instance_eval thing with instance variables:
>
> class E
> =A0 =A0def x(&block)
> =A0 =A0 =A0@x =3D 1
> =A0 =A0 =A0instance_eval(&block)
> =A0 =A0end
> end
>
> @x =3D 2
> p E.new.x { @x } =A0 =A0# 1
>
> Here, since instance variables are always resolved via self, the @x in
> the block is always the @x of the E instance. (I'm not a big fan of
> the stealth instance_eval, for what it's worth.) I think something
> analogous is (now) going on with constants.
>


yes, it's similarly confusing i agree.

> (I do not mean that self is the same as an enclosing class, nor that
> instance variables are the same as constants, nor anything else that I
> didn't say unless it's very insightful and brilliant :-)
>
> I'm not sure about how this plays out with regard to the technical
> definition of a closure. I've always taken it to mean the local
> variable bindings, and not necessarily the rest of the runtime state.
>


the fact that you have always been able to do

  caller =3D eval 'self', block

leads me to believe it's deliberately meant to be much much more in
ruby.

cheers.