[ruby-core:50350] Re: [ruby-trunk - Feature #4085] Refinements and nested methods

In message "Re: [ruby-core:50338] [ruby-trunk - Feature #4085] Refinements and nested methods"
    on Fri, 30 Nov 2012 04:05:15 +0900, "headius (Charles Nutter)" <[e-mail]> writes:

|>  Any more questions?
|
|Yes, lots! :)
|
|* Will we make more methods have special access to the caller's frame to support refinements? I'm speaking here of modifications to send, method reflection, to_proc, and so on. Of these, send sorta has access to caller frame, but it's unspecified (send :binding behaves differently on different impls). The reflection methods (method, instance_method, ...) and to_proc do not currently have access to caller's frame, and would have to be special-cased (and in JRuby that would force deoptimization of code that calls them to ensure we have a frame available).  I would argue that *none* of these methods should see the effects of refinements, because they are not defined within a refined file or scope. Making them see refinements extends refined effects down-stack in unpredictable ways.

From usability perspective, all retrospective methods e.g. respond_to?
methods etc. should reflect refinements. But for 2.0, I don't make
them check refinements, because of performance and complexity.  It
should be issue of future version.

|* Questions about about the scoping of refinements in seemingly unrelated refine blocks.
|
|* Performance expectations. Is performance being completely ignored here, or shall we set some goals for the implementation? I appreciate your desire to make Ruby more expressive, but that doesn't pay the bills at the end of the day if refined calls are 100x slower than regular calls. Some consideration of performance needs to be made up front. I would propose that unless refined calls can be made exactly the same speed as unrefined calls, they should not be included. We'd essentially be adding a file-scoped feature that hurts performance of all calls in that file. Expressivity doesn't trump slowing an entire system down because of a single call made at the top level of a file.

My expectation is that if you don't see "using" and "refine" in the
source code, the performance will not be affected, as much as
possible.  It's the reason I gave up refinements in the module bodies,
inherited modules/classes and module_eval.  I don't demamd refined
call to be exact same speed as unrefined ones, but I'd expect them not
significantly slower.  I'd accept them if they are 5-15% slower than
normal calls.

							matz.