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

Speaking as someone who writes a lot of libraries, I would be very likely to
use a purely lexical refinement feature all the time.

If the feature *was* limited to a purely lexical scope, most of my gems
would probably have a refinements module which I would "using" into the rest
of my code. This would allow me to get the benefit of the extra readability
of core class extensions without leaking those changes to other code.

On the other hand, if the feature leaked via local rebinding or via
inheritance, I would be much less likely (let's say, extremely unlikely) to
use the feature, instead being constantly paranoid that I could leak
refinements to code that didn't expect it (either by people subclassing my
classes or by leaking refinements to callees of my code not controlled by
me).

On the flip side, I would also be scared that people calling into my code
could leak refinements into my code, and probably take steps to protect my
code from that.

In short, this feature could either be really good (truly lexically scoped
"monkey patch protection") or really bad (conceptually as bad as it is now,
but harder to debug).

The difference is whether the feature, by default, never ever leaks
refinements into other scopes.

Yehuda Katz
Architect | Strobe
(ph) 718.877.1325


On Mon, Dec 6, 2010 at 1:23 PM, mathew <[e-mail]> wrote:

> On Sat, Dec 4, 2010 at 06:31, Charles Oliver Nutter <[e-mail]>wrote:
>
>> 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.
>>
>
> Since I view refinements as a horrible feature I'll never use, I like the
> idea of limiting the performance hit to only code that explicitly asks for
> it at file level.
>
>
> mathew
>