[ruby-core:33570] Re: [Ruby 1.9-Feature#4085][Open] Refinements and nested methods

Hi,

2010/12/4 Charles Oliver Nutter <[e-mail]>:
>>> * "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?
>
> Every little bit matters. In experimental optimizations, JRuby is able
> to reduce a dynamic call to two memory indirections + compare + static
> dispatch directly to jitted code. When the dispatch path is this fast,
> adding multiple additional layers of memory indirection and comparison
> to support rarely-changing refinements can definitely show up. I also
> have not attempted to implement an optimized version of refinement
> dispatch, and I worry that there will be additional
> performance-impacting issues.

I see.

>> What do you think of refine? hould it also be a keyword?
>> How about refinements activation in reopened definitions and
>> refinement inheritance?
>> Can all they be problems?
>
> refine as keyword: I don't think so, since it, like many other
> meta-programming methods, applies its changes only once to the
> class/module that surrounds it and the block it has been given. It's
> very "magical", but I'm not sure that's enough of a reason to make it
> a keyword.

I'm also not sure.

> refinement activation in reopened definition: Reopened definitions are
> hierarchies of new lexical scopes. If a refinement is active for those
> scopes it will only affect them and no other scopes. Obviously you
> should not be able to apply a new refinement to scopes that have
> already been closed without refinements in place. That is my #1
> concern with this proposal...what is static (as in StaticScope in
> JRuby) should remain static. I don't believe "refine" or refinements
> applied in reopened classes violate that rule.

I see.

>>> * 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. t should also check the refinements in
>> cref to avoid this problem,
>> but it causes more overhead.
>
> More overhead is always bad if it affects performance globally :)

I thought you might say that, but I did it ;)

>> I might withdraw the proposal of refinement propagation for blocks
>> given to instance_eval,
>> but what do you think of instance_eval without blocks?
>>
>> .instance_eval("...")
>
> This form is "safe" since the string needs to be parsed and evaluated
> (and provided with a new scope) each time. I worry a bit about the
> inconsistency of having the "" form propagate refinements but the {}
> form not propagating refinements. Perhaps this is a big like the
> duality of constant lookup inside instance_eval?

I think the inconsistency is not a problem because the "" form and the
{} form are already inconsistent as to constant lookup as you say.

>> 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.
>>
>> t "should ..." do
>> foo = Foo.new
>> foo.should == ...  Object#should is available only in the block.
>> nd
>
> Yes, I agree this is a useful and difficult case to address. One
> possible solution would be making the modification of the block
> explicit and permanent:
>
> p = proc { bar }
> p.refine! BarModifyingExt
> # p from now on has BarModifyingExt's refinements applied to it

It's an interesting idea.

> To be honest, I think it should be a using directive at the file's
> toplevel, so subsequently-parsed blocks know they're going to be
> refined. I believe more and more that "using" needs to be a keyword;
> having yet another "magic" method that can alter parse/execution
> behavior beyond its scope scares me.

I understand your worry.  But refinements are still immature in other
aspects than performance, so I'd like to experiment on refinements
before improving performance.  Methods are easier than keywords to do
it.

-- 
Shugo Maeda