From: Shugo Maeda <shugo@...>
Date: 2010-11-25T22:48:49+09:00
Subject: [ruby-core:33381] Re: [Ruby 1.9-Feature#4085][Open] Refinements and nested methods

Hi,

2010/11/25 Yusuke ENDOH <mame@tsg.ne.jp>:
>> However, I'm afraid that there are too many patches, some of which
>> have been already reverted.
>
> Please fair them :-)

I have tried "git rebase -i", but these commits are hard to reorder
because they are related to each other.  So I have to separate the
whole patch manually.

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

> After my short trial of this feature, I'd like an API to do
> `refine' and `using' at once without explicit module, such as:
>
> �using_refine(Fixnum) do
> � �def /(other) quo(other) end
> �end
>
> (equivalent to)
>
> �using(Module.new do
> � �refine(Fixnum) do
> � � �def /(other) quo(other) end
> � �end
> �end)

I forgot to mention that refinements are enabled in class or module
definitions where Module#refine is called.

  class Foo
    refine Fixnum do
      def /(other) quo(other) end
    end

    p 1 / 2  #=> (1/2)
  end

Do we need Kernel#refine?

> I guess that this `using_refine' is useful itself (though its
> name is arguable). �In addition, it allows us to write
> MyXmlFormat as follows:
>
> �module MyXmlFormat
> � �using_refine(Integer) do
> � � �def to_xml; ...; end
> � �end
>
> � �using_refine(String) do
> � � �def to_xml; ...; end
> � �end
>
> � �using_refine(Hash) do
> � � �def to_xml; ...; end
> � �end
> �end

I guess Module#refine works the same as using_refine in this case.

>>> � �IMO, it will be more natural to provide this feature as new
>>> � �constract with new syntax, instead of Module's methods.
>>
>> First, I consider it, but I wouldn't like to introduce new keywords.
>
> I thought so, but I think that this feature deserves new
> keywords because it is big evolution of Ruby's OO paradigm
> (involving semantics change).
> However, we should discuss this topic (new keyword) towards
> 2.0. �Module's methods are not bad, as a part of reflection
> features (such as Module#define_method for `def' keyword).

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.

>>> �- Is it intended to reject refining module methods?
>> It's limitation of the current implementation.
>
> If so, it may be good to raise a NotImplementedError.

Agreed.

>> However, I don't think it's critical, because If you'd like to refine
>> a module, you can refine a class which includes the module instead.
>
> Do you mean:

I guess it's unlikely that you need refine module functions in
real-world applications.
Why don't you simply override module functions?

    include Math
    def sqrt(x)
      (x >= 0 ? 1 : Complex::I) * super(x.abs)
    end
    p sqrt(-4)

In the case of mix-in modules, you can refine concrete classes which
include mix-in modules.

  class Foo
    include BarMixin
  end
  module Baz
    refine Foo do # instead of refine(BarMixin)
      def method_in_bar_mixin
        ...
      end
    end
  end

-- 
Shugo Maeda