From: Shugo Maeda <shugo@...>
Date: 2010-12-03T14:05:36+09:00
Subject: [ruby-core:33537] Re: [Ruby 1.9-Feature#4085][Open] Refinements and nested methods

Hi,

2010/11/30 Charles Oliver Nutter <headius@headius.com>:
> * "using" not being a keyword requires all calls to check for
> refinements all the time, globally degrading performance.

This means that you should check a flag or something in StaticScope
for every method invocation, and you cannot accept the overhead,
right?

What do you think of refine?  Should it also be a keyword?
How about refinements activation in reopened definitions and
refinement inheritance?
Can all they be problems?

> * instance_eval propagating refinements requires all block invocations
> to localize what refinements they use for invocation on every
> activation.
> * shared, mutable structures can't be used to store the active
> refinement, due to concurrency issues
> * there are very likely many more complexities than illustrated here
> that result from the combination of runtime-mutable lexical scoping
> structures, concurrency, and method caching.

As Yusuke showed in [ruby-core:33535], the current implementation has
this problem.
The current implementation checks only the (singleton) class of the
receiver and the VM version.  It should also check the refinements in
cref to avoid this problem,
but it causes more overhead.

I might withdraw the proposal of refinement propagation for blocks
given to instance_eval,
but what do you think of instance_eval without blocks?

  x.instance_eval("...")

And, how about to introduce a new method (e.g.,
Module#refinement_eval) which copies a given block and make the copy
refinement aware?
I think blocks are useful to implement DSLs like RSpec.

  it "should ..." do
     foo = Foo.new
     foo.should == ...  # Object#should is available only in the block.
  end

-- 
Shugo Maed