Issue #13927 has been updated by duerst (Martin Drst).


rocifier (Ryan O'Connor) wrote:
> Using ruby commercially we have discovered that modules are no longer serving their original intended purpose of mixins. Another usage of the module has been shoehorned by using module_function. We have found that when developers use module_function they are converting the module into a new concept, and no longer intend their module to be used as a mixin for classes. Instead the intent of this new type of module is to provide publically accessible class methods without the need for instantiation, and without polluting the global namespace. This usage is becoming potentially more common than the mixin usage.

As far as I understand (and found in many books and blogs,...), the 'classic' explanation of `Module`/`module` is that it serves two purposes:
1) Mixin (e.g. Enumerable), and 2) Namespacing (e.g. Net::HTTP). This is also how Matz explained it last week at his keynote at Ruby Kaigi 2017 (see http://rubykaigi.org/2017/presentations/yukihiro_matz.html).

Based on this understanding, are you saying that there's a third purpose? Or are you thinking about module_function as part of, or a variant of, the second purpose? In both cases, why do you think that your purpose should be split out syntactically, while the 'classic' two purposes stay with the same syntactic device? Or if you have another understanding, then please explain.

Also, the most well known `module_function` example is probably `Math.sin` and friends. However, as Ruby is an object-oriented language, my personal preference would be to simply write `0.3.sin` rather than `Math.sin 0.3`. I'd expect that commercial applications also would prefer object-oriented architecture and syntax to (namespaced) global functions. What do you think is the reason that you observe extended use of module_function?


> I propose that we integrate the module_function pattern as its own core ruby object along with Module and Class.

Any kind of proposal of how you imagine this to look?

----------------------------------------
Feature #13927: Integrate module_function as a core language type
https://bugs.ruby-lang.org/issues/13927#change-66872

* Author: rocifier (Ryan O'Connor)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
Using ruby commercially we have discovered that modules are no longer serving their original intended purpose of mixins. Another usage of the module has been shoehorned by using module_function. We have found that when developers use module_function they are converting the module into a new concept, and no longer intend their module to be used as a mixin for classes. Instead the intent of this new type of module is to provide publically accessible class methods withoutthe need for instantiation, and without polluting the global namespace. This usage is becoming potentially more common than the mixin usage.

I propose that we integrate the module_function pattern as its own core ruby object along with Module and Class.



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

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>