Feature #7250: A mechanism to include at once both instance-level and class-level methods from a module

• Status: Open
• Assignee: -
• Target version: -

[alexeymuranov (Alexey Muranov)]

=begin
I have simply commented first on #7240, but i feel i need to start a ticket in order to not post off topic.

This seems to be a big feature request, so i didn't feel confident to suggest, but when i read in #7240 that (({Module#included})) hook can become even more hooked, i've decided to express myself.

=== Proposal

In my opinion, the most common use case for the "(({included}))" hook in modules is adding class methods. However, to me this looks hackish and hard to follow. I would have preferred if there was a way to define both instance-level and class-level behavior in a module and include both at once. Here is an API i would suggest:

module M
def foo
'Foo'
end

def base.bar  # here a fictional private method Module#base is called
  'Bar'
end

end

class C
include M
end

a = C.new
a.foo # => 'Foo'
C.bar # => 'Bar'

This means that a module would need to store 2 method tables, one as usual, and a second one defined as singleton methods on some object returned by some private method, called for example (({Module#base})). Since ordinary objects have no method table, classes have one method table, why not to allow modules to have 2 method tables?

=== Relevant considerations

1. Talking about method tables, maybe if objects were allowed to have one, there would be no need for meta-classes? (Then classes would have 2 method tables, modules would have 3, and in fact methods and method tables could be regarded as kinds of attributes.) It looks to me like meta-class is simply there to make up for the fact that objects are not allowed to keep their own methods.

2. Allowing modules to have more method tables than classes may look like breaking the inheritance (({Class < Module})), but to me this inheritance does not look like a good idea anyway. For example, a module can be included, but a class cannot. To me, class looks like an object factory, but a module like a container of parts that can be unpacked and mounted onto a class.

=== Irrelevant considerations

I think that from the point of view of English, the method name "(({included}))" is not consistent with the method name "(({extended}))" (the module is included, but the base is extended).

I would have preferred if the word "(({extend}))" was used instead of "(({include}))" when "including" one module into another, as this operation seems somewhat different from including a module into a class. I understand that it makes no sense to discuss this now, when (({extend})) is already has its fixed meaning.
=end

[mame (Yusuke Endoh)]

• Target version set to 2.6

[alexeymuranov (Alexey Muranov)]

I have fantasized a bit more about an alternative Object Model for
Ruby. Here is what i imagined:

1. Objects are allowed to keep their methods more or less the same way as they keep attributes in instance variables. Methods are constant-like attributes, redefining a method generates a similar warning as assigning to a constant. (There is no real difference between methods and data, but there is a somewhat real difference between "constant" and "mutable" data.)

2. Objects of Class class, that is classes, have a constant INSTANCE_PROTOTYPE of class BasicObject, and the def's define methods on the object referenced by this constant. When a method is called on an object, the method is first looked up in the method table of this object, then in the method table of the INSTANCE_PROTOTYPE of the object's class, then in the method table of the INSTANCE_PROTOTYPE of the ancestor class, etc. (In some sense, object's methods are "shallow copies" of the methods of the instance prototype of the object's class, but they are copied not one-by-one, but by whole method tables, like environments.)

3. Objects of Module class, that is modules, have a constant EXTENSIONS_FOR initialized with Hash.new { |h, k| h[k] = BasicObject.new }, def's inside the module define methods on the object EXTENSIONS_FOR[:INSTANCE_PROTOTYPE], Module#base returns EXTENSIONS_FOR[:self], so "def base.foo; ... end" defines a method foo on EXTENSIONS_FOR[:self], etc.

4. Instead of inheriting Class from Module, both inherit from a new class Namespace.

Edited 2014-02-26

[naruse (Yui NARUSE)]

• Target version deleted (2.6)