From: Yehuda Katz Date: 2010-12-07T04:30:19+09:00 Subject: [ruby-core:33603] Re: [Ruby 1.9-Feature#4085][Open] Refinements and nested methods --0016368e32bb7c92b50496c2eaf7 Content-Type: text/plain; charset=ISO-8859-1 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 wrote: > On Sat, Dec 4, 2010 at 06:31, Charles Oliver Nutter 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 > --0016368e32bb7c92b50496c2eaf7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Speaking as someone who writes a lot of libraries, I would be very likely t= o use a purely lexical refinement feature all the time.

= If the feature *was* limited to a purely lexical scope, most of my gems wou= ld 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 re= adability of core class extensions without leaking those changes to other c= ode.

On the other hand, if the feature leaked via local rebi= nding or via inheritance, I would be much less likely (let's say, extre= mely 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 ca= lling into my code could leak refinements into my code, and probably take s= teps to protect my code from that.

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

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

Yehud= a Katz
Architect | Strobe
(ph) 718.877.1325


On Mon, Dec 6, 2010 at 1:23 PM, mathew <= span dir=3D"ltr"><meta@pobox.com&g= t; wrote:
On Sat, Dec 4, 2010 at 06:31, = Charles Oliver Nutter <headius@headius.com> 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.=A0<= /div>


mathew

--0016368e32bb7c92b50496c2eaf7--