From: Shugo Maeda <shugo@...>
Date: 2010-11-26T11:02:28+09:00
Subject: [ruby-core:33393] Re: [Ruby 1.9-Feature#4085][Open] Refinements and nested methods

Hi,

2010/11/26 Yusuke ENDOH <mame@tsg.ne.jp>:
>> How about to separate them into the following three patches?
>>
>> �1. changes of control frames and method lookup
>> �2. Refinements support
>> �3. nested methods support
>
> Seems good.

I'll make the patches.

>> Do we need Kernel#refine?
>
> I want it.

I agree with you.  What do you think of it, Matz?

>> I guess Module#refine works the same as using_refine in this case.
>
> Hmm. �Then, when no block is given to Module#refine, how about
> adding an implicit block that includes the outer module?
>
> �module FooExt
> � �refine(Foo)
> � �...
> �end
>
> (equivalent to)
>
> �module FooExt
> � �refine(Foo) { include FooExt }
> � �...
> �end

Could you tell me why you need this feature?

>> I don't think we need new keywords even if it is a big change,
>> because some essential features such as module inclusion
>> have no keyword in Ruby.
>
> Indeed. �But conventionally, essential features that involve
> code block (such as class/module definition, method definition
> and control statements) have their special keywords.

I guess that most of these constructs have reasons why they need
keywords and special syntax.  For example, class, module, and method
definitions take undefined identifiers (alias doesn't invoke code
block, but it's a keyword for the same reason), and some control
statements take expressions evaluated lazily.  However, there is no
such reason for Refinements.

If refine is a keyword, there is one good thing.  We don't need "do"
after class names.

  refine Fixnum
    ...
  end

I'm not sure it's an enough reason to introduce a new keyword.
What do you think of it, Matz?

>> I guess it's unlikely that you need refine module functions in
>> real-world applications.
>
> I thought that one of motivating examples of this feature is
> mathn.rb. �In fact, mathn.rb changes Math module to complex-
> aware one.

If think it's better to provide complex-aware features as module functions
of a new module such as MathN or MathN::Math.  Users can include it
instead of Math.

-- 
Shugo Maeda