I have a piece of code that does something like the following:
class Foo
A = 1
end
def foo(&block)
f = Foo.new
f.instance_eval(&block)
end
foo() do
p self #=> #Foo:0x4027f568
p self.class::A #=> 1
p A #=> 1 on 1.6.7; NameError on 1.7 and 1.6.8
end
What has changed in Ruby to cause this behavior? Is there a change I
can make to foo() or to Foo to allow the block passed to foo() to work?
Thanks,
Paul
Hi –
Hi,
What has changed in Ruby to cause this behavior? Is there a change I
can make to foo() or to Foo to allow the block passed to foo() to work?
I wanted to make constant scope more static. It’s for readability and
for future optimization. There’s no way to switch constant scope.
I can only give “feeling” arguments here… but this error feels very
strange to me:
a = Object.new
a.instance_eval { B = 1; puts B } # error on the puts
It’s probably not a very common construct, but it still feels like
it’s a significant change in the principle of instance_eval (i.e.,
dynamically switching to the ‘self’ scope of the receiver).
Can you elaborate on the pros and cons of (not) switching constant
scope?
David
···
On Fri, 27 Dec 2002, Yukihiro Matsumoto wrote:
In message “change in lookup of constants on 1.6.8?” > on 02/12/27, Paul Brannan pbrannan@atdesk.com writes:
–
David Alan Black
home: dblack@candle.superlink.net
work: blackdav@shu.edu
Web: http://pirate.shu.edu/~blackdav
I can see how this would help in optimization. How does it add
readability?
How big a performance boost do you expect this change (plus future
optimizations) to give?
Paul
···
On Fri, Dec 27, 2002 at 12:44:32PM +0900, Yukihiro Matsumoto wrote:
In message “change in lookup of constants on 1.6.8?” > on 02/12/27, Paul Brannan pbrannan@atdesk.com writes:
What has changed in Ruby to cause this behavior? Is there a change I
can make to foo() or to Foo to allow the block passed to foo() to work?
I wanted to make constant scope more static. It’s for readability and
for future optimization. There’s no way to switch constant scope.
Hi,
I wanted to make constant scope more static. It’s for readability and
for future optimization. There’s no way to switch constant scope.
I can see how this would help in optimization. How does it add
readability?
if constant scope resolved in the compile time, constant access can be
direct slot access, which can be much faster than chained hash
access. Besides, you will know the role of constant identifiers
without dynamic information.
How big a performance boost do you expect this change (plus future
optimizations) to give?
Currently none; not much in the future.
matz.
···
In message “Re: change in lookup of constants on 1.6.8?” on 02/12/28, Paul Brannan pbrannan@atdesk.com writes: