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

Hi,

2010/12/3 Yusuke ENDOH <[e-mail]>:
>>> I'm not against using modules as namespaces and refinement scope,
>>> but I don't like to see the same module being used for refinement
>>> and traditional use at the same time.
>>> Modules for mix-in, modules for collection of helper methods, and
>>> modules for refinement should be separated, at least, in casual
>>> use.
>>
>> I agree with you. ut I don't think Ruby should enforce it.
>
> Yes. n fact, I'm ok even if the block style API is *also* included.
> However, Ruby can (and should) "navigate" user to encouraged style,
> by making encouraged API more useful, such as using shorter method
> name.

Hmm, I prefer the keyword refine to the method refine without blocks....

>> I don't like this style as the primary way because it can be used for
>> only one class.
>
> We can use the block style API for such a use case:
>
> module FooBarBazExt
> refine_eval Foo do
> def ext; end
> end
> refine_eval Bar do
> def ext; end
> end
> refine_eval Baz do
> def ext; end
> end
> end

refine_eval doesn't look a good name.  I don't think the above code
should be so discouraged.

> However, it would be better to separate modules, especially when the
> code grows:
>
> module FooExt
> refine Foo
> def ext1; end
> def ext2; end
> def ext3; end
> ...
> end
> module BarExt
> refine Bar
> ...
> end
> module BaZExt
> refine Baz
> ...
> end
>
> module FooBarBazExt
> using FooExt # or include FooExt
> using BarExt
> using BazExt
> end
>
>
> ... Oops! his does not work as excepted.  had believed that this
> would work... hy don't you allow this?

Currently refine doesn't work without blocks, but do you mean that?

>> To tell the truth, I can accept new keywords refine and using, but I'm
>> afraid it makes Refinements a Ruby 2.0 feature.
>
> Your suggestion is really well-conceived, but still needs discussion.
> If it is included in 1.9.x once, we cannot change the interface because
> of compatibility. hus, we should take cautious steps to include the
> feature.
>
> As a first step, how about including only the mechanism and its
> *undocumented* C API, and publishing a refinement gem for Ruby API?
> Then, trunk developers can easily examine the feature by using the gem.
> We can also examine the actual performance. f we find any problem or
> came up with a better idea, we can change the API without care of
> compatibility (because it is just an undocumented API and an untrustful
> gem!), or even remove and forget it at worst.

I think it's hard to add new keywords by a gem.  Have you abandoned
keywords?  I prefer to the keyword refine to the method refine without
blocks suggested by you.

Isn't it enough to introduce refinements as an experimental feature,
at least in trunk?

-- 
Shugo Maeda