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

On Fri, Nov 2, 2012 at 7:12 PM, shugo (Shugo Maeda)
<[e-mail]> wrote:
> headius (Charles Nutter) wrote:
> > * Refinements in modules and class hierarchies does not seem like a pro=
blem to me yet.
> > * Refinements are "used" in temporal order...methods added before "usin=
g" won't see refinements, refinements added after "using" won't be applied.=
 I think this is a good thing, since it allows us to have a one-shot flag f=
or refinements on methods at definition time.
>
> The current behavior is mainly for an implementation reason, but Matz and=
 ko1 seem not to like it:(

I commented on ko1's bug. I see using a bit like visibility changes,
only affecting methods defined later on.

I understand the implementation reason as well...in order to limit the
damage of refinements, your impl flags methods as having refinements
active. For optimization purposes, that means we know at definition
time whether we need to handle refinements at all.

> > * Months ago when the original proposal came out, I expressed my concer=
n about refinements applying to module_eval and friends. I still strongly o=
bject to this behavior.
>
> I also wonder whether module_eval with blocks should be affected by refin=
ements or not, but I think module_eval with strings (e.g., M.module_eval("C=
.new.foo")) has no problem, right?

String eval would not be a problem, that is correct. We would be able
to see at eval time that the target module has refinements active.

> > This is dynamic application of refinements, which has been hotly debate=
d and which I *thought* was supposed to be removed. I assume it has been le=
ft in because it is required to apply refinements "magically" to all-block =
code like rspec. I do not see this as an excuse to introduce such an unpred=
ictable feature.
>
> instance_eval and module_eval themselves have the same problem because th=
ey change self "magically".
> At first, I thought they are evil, but they are popular now.
> I'd like to ask Matz's opinion.

Yes, module_eval, class_eval, and instance_eval are all problematic
because of the self changing, but module_eval and class_eval are
especially bad if they force refinements on code that doesn't know
about them.

I am starting to see some intractable problems with refinements, unfortunat=
ely.

In order to avoid having every call in the system check for
refinements, they are applied in evaluation order. However, this means
that the load order of scripts can now completely change which methods
get called. For example...

a.rb:

class Foo
  def go(obj)
    obj.something
  end
end

b.rb:

class Foo
  using Baz # refines the "something" call
end

If the files are loaded in the order a, b, no refinements are applied
to the something call. If b is loaded before a, refinements are
applied to the something call. No other features in Ruby are so
sensitive to load order (other than those that introspect classes and
methods, obviously).

The alternative is to have refinements not be applied temporally.
However this means every call in the system needs to check for
refinements every time. Given the complexity of method lookup in Ruby
today, adding refinements to that process seems like a terrible idea.

In order to cache a method call in the presence of refinements, we
need to track all of the following:

1. whether any refinements are active
2. whether there are refinements that affect the class of the target
of the method call
3. whether refinements that affect the target class redefine the target met=
hod

If any of these change at any time, we need to invalidate the cache.
This is on top of all the information we need to do to cache methods
normally.

At this point I would not vote for refinements to be included in Ruby
2.0. I feel like there are far too many edge cases and implementation
concerns.

I will continue my investigation.