[ruby-core:48702] [ruby-trunk - Feature #7250] A mechanism to include at once both instance-level and class-level methods from a module

Issue #7250 has been updated by alexeymuranov (Alexey Muranov).


=begin
I have fantasized a bit more about an alternative Object Model for
Ruby.  Here is what i have thought of:

1. Objects are allowed to keep their methods more or less the same way as
they keep attributes in instance variables.

2. Objects of (({Class})) class, that is classes, have an attribute
(({@__instance_prototype__})) of class (({BasicObject})), and the (({def}))'s define
methods on this attribute, which are copied over when creating class
instances.

3. Objects of (({Module})) class, that is modules, have attributes
(({@__instance_prototype_extension__})) and (({@__self_extension__})) of class (({BasicObject})),
(({def}))'s define methods on (({@__instance_prototype_extension__})),
(({Module#base})) or (({Module#inclusion_base})) returns (({@__self_extension__})), etc.
=end

----------------------------------------
Feature #7250: A mechanism to include at once both instance-level and class-level methods from a module
https://bugs.ruby-lang.org/issues/7250#change-32153

Author: alexeymuranov (Alexey Muranov)
Status: Open
Priority: Normal
Assignee: 
Category: 
Target version: next minor


=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



-- 
http://bugs.ruby-lang.org/