Hi,

2010/12/3 Shugo Maeda <shugo / ruby-lang.org>:
> 2010/12/2 Yusuke ENDOH <mame / tsg.ne.jp>:
>>> My proposal is to use modules as namespaces for refinements.  So
>>> indentation is a necessary evil.  Otherwise, we need syntax like Java
>>> packages and one file for each package.
>>
>> 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.


>> We can clearly see that the following module FooExt is only for
>> refinement.  Thus I like this style.
>>
>>  module FooExt
>>    refine Foo
>>    def ... end
>>  end
>
> 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

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?


>> Because block includes method definition.  A block looks to me
>> "dynamic" behavior, while method definition (using `def' keyword)
>> looks "static" behavior.
>> Of course I know that both are also evaluated dynamically in
>> Ruby, but I don't think that Ruby encourages such a style so much.
>
> method definitions don't look static for me, but nari said the same....
> My brain might be too optimized for Ruby.

Many men, many (pseudo) Ruby.  My (and nari's) Ruby could be wrong.
Only matz has the true Ruby.  We should ask his opinion.


> 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.

# Of course, this is a topic after the discussion is closed.

-- 
Yusuke Endoh <mame / tsg.ne.jp>