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

Perhaps refinements should be scoped per-gem, rather than any arbitrary
"using" delimitation. Seems to me, that is generally the level at which we
care about them.

Would that simplify implementation and comprehensibility of usage to
something more manageable?


On Wed, Nov 14, 2012 at 1:35 PM, Aaron Patterson
<[e-mail]>wrote:

> On Wed, Nov 14, 2012 at 05:38:12AM +0900, headius (Charles Nutter) wrote:
>
> [snip]
>
> > And then there's this:
> >
> > class Foo < SomeParent
> >   def baz(str)
> >     ary.map {|name| str.camelize + name}
> >   end
> > end
> >
> > In this case, you have to check even more places for refinements to know
> what methods will be called:
> >
> > * Foo may have been previously refined. You must look for all reopenings
> of Foo to know what will be called.
> > * SomeParent or its parents may have been previously refined. You must
> look for all reopenings of SomeParent and its parents.
> > * The map method may force refinements on the block. you must look for
> all implementations of map() that might be called here to see if they force
> refinements into the block.
> >
> > This is supposed to be simpler?
>
> I have to agree.  It seems like this would be *much* more difficult to
> debug than if `camelize` is just monkey patched on to String.
>
> This code:
>
>   class Foo < SomeParent
>     def baz(str)
>       cached = str.camelize
>       ary.map {|name| cached + name}
>     end
>   end
>
> Could have a completely different meaning than this code:
>
>   class Foo < SomeParent
>     def baz(str)
>       ary.map {|name| str.camelize + name}
>     end
>   end
>
> That seems extremely bad.
>
> --
> Aaron Patterson
> http://tenderlovemaking.com/
>
>


-- 
Sorry, says the barman, we don't serve neutrinos. A neutrino walks into a
bar.

Trans <[e-mail]>
7r4n5.com      http://7r4n5.com