From: Trans <transfire@...>
Date: 2007-06-22T05:17:19+09:00
Subject: Modular classes and avoiding extension clashes

I refer back to:

  Ruby-talk: 240334

 
http://groups.google.com/group/ruby-talk-google/browse_thread/thread/9dbe8cd0898227b5/409301042321f6fc?lnk=gst&q=open+class+module+trans&rnum=2&hl=en#409301042321f6fc

I've thought of another potential benefit of this approach. While I
had believed it would be only reasonable to have a single anonymous
module per class, there may be greater benefit in multiple modules. B/
c, it may make possible the avoidance of extension clashes. Here's an
example:

  # friend1.rb
  class String
    def exclaim; self + '!'; end
    def scream; exclaim + '!!'; end
  end
  ...

  # friend2.rb
  class String
    def exclaim; puts self + '!'; end
    def scream; exclaim; exclaim; end
  end
  ...

  # elsewhere.rb
  require 'firend1'
  require 'firend2'

Clearly there's a conflict. How can I use friend1#scream but also
friend2#scream? One's first thought could well be to alias the method
so it's under a different name:

  # elsewhere.rb
  require 'firend1'

  class String
    alias :friend1scream, :scream
  end

  require 'friend2'

  "hey".firend1scream

However, #exclaim is called by #scream so it will still not work as
expected.

So getting back to the original suggestion (of the previous thread),
having open extensions contained in hidden modules... what if method
lookup followed a route of first checking within the same module, then
continuing upward before dropping back to ancestors? In other words if
we had a class, C < M1 < M2 and a method was called on it that is
defined in M2, then any method the M2 method calls would first be
looked for in M2, then M1, before falling back to Object and Kernel.
This would resolve the problem with the above example.

It seems to me this is not necessarily unexpected behavior either. If
I create a method A that depends on a another method B, clearly
overriding B is dangerous business --it's something not generally
done. Usually it's the "top most" methods --the ones that depend on
others, that we override. That's not to say there aren't cases to do
so, but in that case a 'redef' keyword could be used explicitly.

T.