https://bugs.ruby-lang.org/https://bugs.ruby-lang.org/favicon.ico?17113305112017-09-22T05:21:13ZRuby Issue Tracking SystemRuby master - Feature #13927: Integrate module_function as a core language typehttps://bugs.ruby-lang.org/issues/13927?journal_id=668312017-09-22T05:21:13Zmatz (Yukihiro Matsumoto)matz@ruby.or.jp
<ul></ul><p>I admit modules with module_function play different role from ordinary modules, and so do refinements.<br>
I am not sure how much gain we would have by making them their own objects. Adding new syntax, keywords, or concepts may make the language slightly more understandable, but may introduce incompatibility, that everyone hates.</p>
<p>Matz.</p> Ruby master - Feature #13927: Integrate module_function as a core language typehttps://bugs.ruby-lang.org/issues/13927?journal_id=668362017-09-22T10:18:37Zrocifier (Ryan O'Connor)rocifier@gmail.com
<ul></ul><p>matz (Yukihiro Matsumoto) wrote:</p>
<blockquote>
<p>I admit modules with module_function play different role from ordinary modules, and so do refinements.<br>
I am not sure how much gain we would have by making them their own objects. Adding new syntax, keywords, or concepts may make the language slightly more understandable, but may introduce incompatibility, that everyone hates.</p>
<p>Matz.</p>
</blockquote>
<p>Hi Matz thanks for your reply. I think we would have a reasonably significant gain in making the language easier to pick up for newcomers, as well as allowing existing developers to opt-in to creating more concise and readable code.</p>
<p>In terms of compatibility, I suppose we would need to keep backwards compatibility in a feature like this. The downside I can think of is if people need to downgrade the version of ruby they are using, which admittedly does happen from time to time. My only answer to this is that it could be an automated rubocop fix (as an example) to easily go from one syntax to the other.</p> Ruby master - Feature #13927: Integrate module_function as a core language typehttps://bugs.ruby-lang.org/issues/13927?journal_id=668482017-09-23T21:20:01Zshevegen (Robert A. Heiler)shevegen@gmail.com
<ul></ul><p>I wanted to write a reply but it was too long, so here just a shorter one.</p>
<p>Even new syntax may make a language more complex but also simpler at the same time.<br>
People may have to learn/understand what a concept means in a language. New features<br>
may provide more flexibility but often make a language also more complex. A good example<br>
are <strong>refinements</strong> - they are not so difficult to understand but there is some syntax<br>
(how to activate a refinement) and people may have to understand how refinements<br>
work and whether they are limited. I think there was some presentation a while ago<br>
about "nobody uses refinements" or something like that, which reminds me of "nobody<br>
knows nobu", until the epic storyline was revealed where Nobu arose rom Mt. Fujimoto. :)</p>
<p>Anyway, not going to write too much, but when I was writing my longer reply, I actually<br>
wondered whether this change targeted ruby 2.x or ruby 3.x.</p>
<p>Rocifier, can you say which ruby you have had in mind primarily?</p>
<p>If ruby 3.x, I guess it may be possible to also release "future" ruby builds more frequently<br>
that are pre-ruby 3.x, with more experimental changes so that people can test them extensively<br>
well before ruby 3.x will be finalized. Not just in regards to the module_function situation<br>
(I am neutral on this) but in general. This may also allow people to add new features into<br>
ruby - like developer A is very fast, developer B is slower and the code has to be more<br>
complex, so other ruby hackers could test code from developer A more frequently in these<br>
ruby pre-3.x builds.</p>
<p>If ruby 2.x then this is much harder. Not everyone wants to be required to have to adjust<br>
syntax code all of a sudden and not everyone knows how to use rubocop either or wants to<br>
be required to have to use it.</p> Ruby master - Feature #13927: Integrate module_function as a core language typehttps://bugs.ruby-lang.org/issues/13927?journal_id=668722017-09-25T07:23:16Zduerst (Martin Dürst)duerst@it.aoyama.ac.jp
<ul></ul><p>rocifier (Ryan O'Connor) wrote:</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>As far as I understand (and found in many books and blogs,...), the 'classic' explanation of <code>Module</code>/<code>module</code> is that it serves two purposes:</p>
<ol>
<li>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 <a href="http://rubykaigi.org/2017/presentations/yukihiro_matz.html" class="external">http://rubykaigi.org/2017/presentations/yukihiro_matz.html</a>).</li>
</ol>
<p>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.</p>
<p>Also, the most well known <code>module_function</code> example is probably <code>Math.sin</code> and friends. However, as Ruby is an object-oriented language, my personal preference would be to simply write <code>0.3.sin</code> rather than <code>Math.sin 0.3</code>. 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?</p>
<blockquote>
<p>I propose that we integrate the module_function pattern as its own core ruby object along with Module and Class.</p>
</blockquote>
<p>Any kind of proposal of how you imagine this to look?</p> Ruby master - Feature #13927: Integrate module_function as a core language typehttps://bugs.ruby-lang.org/issues/13927?journal_id=668932017-09-25T09:40:35Zrocifier (Ryan O'Connor)rocifier@gmail.com
<ul></ul><p>shevegen (Robert A. Heiler) wrote:</p>
<blockquote>
<p>Rocifier, can you say which ruby you have had in mind primarily?</p>
</blockquote>
<p>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.</p>
<p>duerst (Martin Dürst) wrote:</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>Yes, there is a third purpose in this case.</p>
<blockquote>
<p>Also, the most well known <code>module_function</code> example is probably <code>Math.sin</code> and friends. However, as Ruby is an object-oriented language, my personal preference would be to simply write <code>0.3.sin</code> rather than <code>Math.sin 0.3</code>. 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?</p>
</blockquote>
<p>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 <em>importing</em> 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 <code>module_function</code>. What I am proposing is to split the <code>module</code> + <code>module function</code> combination and name it as something new and separate to module. It wouldn't be a required syntax, at least not for a long time.</p>
<blockquote>
<blockquote>
<p>I propose that we integrate the module_function pattern as its own core ruby object along with Module and Class.</p>
</blockquote>
<p>Any kind of proposal of how you imagine this to look?</p>
</blockquote>
<p>I haven't yet thought up a new name for this duo. If I designed the three concepts from scratch today, I would probably want to propose something like this:</p>
<p><code>Mixin</code> (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)<br>
<code>Module</code> (for the module + module_function replacement with namespacing)<br>
<code>Class</code> (remains as current concept)</p>
<p>However that's too many breaking changes. I will give some more thought into this soon. Welcome other suggestions!</p> Ruby master - Feature #13927: Integrate module_function as a core language typehttps://bugs.ruby-lang.org/issues/13927?journal_id=669062017-09-25T13:11:13Zphluid61 (Matthew Kerwin)matthew@kerwin.net.au
<ul></ul><p>Sounds to me like you want a new type of object which is like <code>Module</code> but can't be <code>include</code>d. If that's the case, I'd suggest a name like <code>Library</code> or <code>Namespace</code>.</p>
<p>I'm still not sold on the value of the proposition. Maybe if its methods were all defined on the singleton class? E.g.:</p>
<pre><code>library Foo
def bar; end
end
Foo.bar #=> nil
</code></pre>
<p>Perhaps that is beyond the scope of the feature.</p> Ruby master - Feature #13927: Integrate module_function as a core language typehttps://bugs.ruby-lang.org/issues/13927?journal_id=669212017-09-25T22:30:49Zrocifier (Ryan O'Connor)rocifier@gmail.com
<ul></ul><p>phluid61 (Matthew Kerwin) wrote:</p>
<blockquote>
<p>Sounds to me like you want a new type of object which is like <code>Module</code> but can't be <code>include</code>d. If that's the case, I'd suggest a name like <code>Library</code> or <code>Namespace</code>.</p>
<p>I'm still not sold on the value of the proposition. Maybe if its methods were all defined on the singleton class? E.g.:</p>
<pre><code>library Foo
def bar; end
end
Foo.bar #=> nil
</code></pre>
<p>Perhaps that is beyond the scope of the feature.</p>
</blockquote>
<p>Yes, something like this :) the value is not huge, I admit, since it is mostly bringing the benefit of readability. However, it is also recognising the two ideas as having distinct purposes at the same syntactic level.</p>