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)" <headius=
@headius.com> writes:

|>  Any more questions?
|
|Yes, lots! :)
|
|* Will we make more methods have special access to the caller's frame to s=
upport refinements? I'm speaking here of modifications to send, method refl=
ection, to_proc, and so on. Of these, send sorta has access to caller frame=
, but it's unspecified (send :binding behaves differently on different impl=
s). The reflection methods (method, instance_method, ...) and to_proc do no=
t currently have access to caller's frame, and would have to be special-cas=
ed (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 met=
hods should see the effects of refinements, because they are not defined wi=
thin a refined file or scope. Making them see refinements extends refined e=
ffects down-stack in unpredictable ways.

=46rom 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 consider=
ation 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 th=
at 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 leve=
l 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.