Issue #13927 has been updated by rocifier (Ryan O'Connor).


shevegen (Robert A. Heiler) wrote:

> Rocifier, can you say which ruby you have had in mind primarily?

I hadn't thought about it, just wanted to see what people thought of the idea first initially. But now that you explain this, version 3 makes more sense to me.

duerst (Martin Drst) wrote:

> 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.

Yes, there is a third purpose in this case.

> 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?

Good question. The reason I suppose is that developers don't really see that a class is the right solution to providing namespaced pure functions, since a class has to be instanced, and since what they want to do is call out to a kind of "library" instead of _importing_ a "library" in to each class they want to use a single method or two in (I suppose the Math module is a little "all-or-nothing" like that). What devs I know seem to desire is to be able to implement a very simple solution when they require simple architecture. Perhaps an equivalent in a typed language like Java would be a static class. Whether that is good practice or not I guess is debatable, but the point is rather moot since Ruby provides a way to do this already with `module_function`. What I am proposing is to merge `module` with `module function` and rename it. It wouldn't be a required syntax, at least not for a long time.

> > 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?

If I designed it from scratch today, I would probably want to propose something like this:

`Mixin` (for the classic intention, but I would potentially not have namespacing involved here - instead I would support a practice of nesting a Mixin within a Module as defined below)
`Module` (for the module + module_function replacement with namespacing)
`Class` (remains as current concept)

However that's too many breaking changes. I will give some more thought into this soon. Welcome other suggestions!

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

* 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>