[ruby-core:38159] Questions about Module#mix

Hi,

I have seen Matz propose a new feature: Module#mix several times for
inclusion in a future version of Ruby.

I am unsure about what use-case #mix is attempting to help with. In current
Ruby, all modules are including in the ancestor hierarchy. This means that
it is possible to use modules as a form of runtime extension of the class
hierarchy, and to use `super` between included modules.

This allows us to build an abstract class and several optional modules that
are included into a subclass if they are needed. We use this pattern quite a
lot in Rails. For instance, ActionController::Metal is a superclass, and a
large number of possible ActionController modules are available to perform
different operations. You can see the modules here:
https://github.com/rails/rails/tree/master/actionpack/lib/action_controller/metal.
For instance, there is an ImplicitRender module  (
https://github.com/rails/rails/blob/master/actionpack/lib/action_controller/metal/implicit_render.rb#L3-7),
which overrides action dispatching to render a default if no rendering
occurred.

This pattern is extremely powerful. In contrast, the #mix proposal assumes
that using the same method name is an *error*, and requires renaming the
method in order to proceed. This makes working with multiple cooperating
modules harder and more error-prone.

The one nice thing about #mix is that it inserts the module's methods in
front of the class, rather than behind it. This makes it possible to extend
an existing class that is not architected for cooperating modules (like
Rails is). An alternate open proposal, Module#prepend, would give us the
benefit of extending existing classes while preserving the ability to insert
multiple cooperating modules.

I have attached a diagram showing the three different approaches (Ruby
1.9.2, #mix, and #prepend).

I'd still be concerned if we added both #prepend and #mix, because #mix
introduces new module semantics, so we'd now have two different modules
systems with subtly different semantics. This introduced some of the issues
illustrated in Matz's post a month ago (
http://ruby-dev.route477.net/posts/43620). Even if fixed, it would require
new Ruby users to understand both the mix-style of including modules
(combining into the class), the normal (traditional) style, and any
interactions between the styles.

Thank you for your consideration,

Yehuda Katz
Chief Technologist | Strobe
(ph) 718.877.1325