From: Shugo Maeda <shugo@...>
Date: 2010-12-03T22:04:56+09:00
Subject: [ruby-core:33546] Re: [Ruby 1.9-Feature#4085][Open] Refinements and nested methods

Hi,

2010/12/3 Yusuke ENDOH <mame@tsg.ne.jp>:
>>> 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. �But I don't think Ruby should enforce it.
>
> Yes. �In 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! �This does not work as excepted. �I had believed that this
> would work... �Why 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. �Thus, 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. �If 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