https://bugs.ruby-lang.org/https://bugs.ruby-lang.org/favicon.ico?17113305112016-07-29T19:54:42ZRuby Issue Tracking SystemRuby master - Feature #12637: Unified and consistent method naming for safe and dangerous methodshttps://bugs.ruby-lang.org/issues/12637?journal_id=598322016-07-29T19:54:42Zr.smitala (Radovan Smitala)
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/59832/diff?detail_id=42024">diff</a>)</li></ul> Ruby master - Feature #12637: Unified and consistent method naming for safe and dangerous methodshttps://bugs.ruby-lang.org/issues/12637?journal_id=598432016-07-30T04:53:24Zr.smitala (Radovan Smitala)
<ul><li><strong>Subject</strong> changed from <i>Unificate and consistent method naming for safe and dangerous methods</i> to <i>Unified and consistent method naming for safe and dangerous methods</i></li><li><strong>Description</strong> updated (<a title="View differences" href="/journals/59843/diff?detail_id=42034">diff</a>)</li></ul><p>Fixed typo</p> Ruby master - Feature #12637: Unified and consistent method naming for safe and dangerous methodshttps://bugs.ruby-lang.org/issues/12637?journal_id=598482016-08-01T00:19:56Zshyouhei (Shyouhei Urabe)shyouhei@ruby-lang.org
<ul></ul><p>Array#clear being destructive is the nature of that method. It makes no sense to have its bang variant.</p>
<p>I think you missed the point that a bang method is a variant. No core methods I remember appear in bang without its bang-less counterpart. The use of bang is consistent in that way.</p>
<p>And honestly I don't like the idea of marking every methods with "this is functional" flag. That is a twisted Hungarian notation.</p> Ruby master - Feature #12637: Unified and consistent method naming for safe and dangerous methodshttps://bugs.ruby-lang.org/issues/12637?journal_id=598522016-08-01T08:07:24Zr.smitala (Radovan Smitala)
<ul></ul><p>Shyouhei Urabe wrote:</p>
<blockquote>
<p>Array#clear being destructive is the nature of that method. It makes no sense to have its bang variant.</p>
<p>I think you missed the point that a bang method is a variant. No core methods I remember appear in bang without its bang-less counterpart. The use of bang is consistent in that way.</p>
<p>And honestly I don't like the idea of marking every methods with "this is functional" flag. That is a twisted Hungarian notation.</p>
</blockquote>
<p>I understand that bang (dangerous) methods are variation to normal methods. But in some circumstances it is not clear if method modify receiver or not.<br>
I dont want to just rename methods to variant with exclamation mark. My issue is about redefine methods and also create new variations.</p>
<p>Eg: <strong>fill</strong> which return new array, and <strong>fill!</strong> which modify receiver.</p>
<p>Good example should be this:</p>
<pre><code>[1] pry(main)> ary = [1, 2, 3, 4]
=> [1, 2, 3, 4]
[2] pry(main)> new_ary = ary.fill { |i| i*i }.select { |num| num.even? }
=> [0, 4]
[3] pry(main)> ary
=> [0, 1, 4, 9]
</code></pre>
<p>Original object is modified. Fill method should just return new one. It think it is little bit confuse. Because there is <strong>select</strong> also with bang.<br>
Code written in idea manner ( <a href="http://docs.ruby-lang.org/en/trunk/syntax/methods_rdoc.html" class="external">http://docs.ruby-lang.org/en/trunk/syntax/methods_rdoc.html</a> ) may looks like:</p>
<pre><code class="ruby syntaxhl" data-language="ruby"><span class="c1"># do not modify original variable</span>
<span class="n">new_ary</span> <span class="o">=</span> <span class="n">ary</span><span class="p">.</span><span class="nf">fill</span> <span class="p">{</span> <span class="o">|</span><span class="n">i</span><span class="o">|</span> <span class="n">i</span><span class="o">*</span><span class="n">i</span> <span class="p">}.</span><span class="nf">select</span> <span class="p">{</span> <span class="o">|</span><span class="n">num</span><span class="o">|</span> <span class="n">num</span><span class="p">.</span><span class="nf">even?</span> <span class="p">}</span>
<span class="c1">#modify</span>
<span class="n">ary</span><span class="p">.</span><span class="nf">fill!</span> <span class="p">{</span> <span class="o">|</span><span class="n">i</span><span class="o">|</span> <span class="n">i</span><span class="o">*</span><span class="n">i</span> <span class="p">}.</span><span class="nf">select!</span> <span class="p">{</span> <span class="o">|</span><span class="n">num</span><span class="o">|</span> <span class="n">num</span><span class="p">.</span><span class="nf">even?</span> <span class="p">}</span>
</code></pre>
<p>Anyway it could not be apply to every method. Just for that methods which changing state of receiver.<br>
This is not compatible change. I know it so i opened this topic as discussion.</p> Ruby master - Feature #12637: Unified and consistent method naming for safe and dangerous methodshttps://bugs.ruby-lang.org/issues/12637?journal_id=598532016-08-01T08:25:45Zshyouhei (Shyouhei Urabe)shyouhei@ruby-lang.org
<ul></ul><p>Radovan Smitala wrote:</p>
<blockquote>
<p>Eg: <strong>fill</strong> which return new array, and <strong>fill!</strong> which modify receiver.</p>
</blockquote>
<p>I think this specific method (nondestructive fill variant) is worth considering. Maybe another name (with aliasing foo! to current fill) could be acceptable?</p> Ruby master - Feature #12637: Unified and consistent method naming for safe and dangerous methodshttps://bugs.ruby-lang.org/issues/12637?journal_id=598542016-08-01T09:29:38Zr.smitala (Radovan Smitala)
<ul></ul><p>Shyouhei Urabe wrote:</p>
<blockquote>
<p>Radovan Smitala wrote:</p>
<blockquote>
<p>Eg: <strong>fill</strong> which return new array, and <strong>fill!</strong> which modify receiver.</p>
</blockquote>
<p>I think this specific method (nondestructive fill variant) is worth considering. Maybe another name (with aliasing foo! to current fill) could be acceptable?</p>
</blockquote>
<p>It is not about fill. New method name with same function just fragmentize language.<br>
It is about manner which is used in Ruby language. Idea about "safe" and "dangerous" methods is very clear and understandable.<br>
Safe methods do not change receiver, dangerous do. Easy and solid behaviour. When i want to modify data, but not variable, use safe. When i want to modify variable itself, use dangerous.<br>
But currently names are mixed with their behaviour. It looks like safe method, but bam, modify receiver itself.</p>
<p>Class String <a href="http://docs.ruby-lang.org/en/2.3.0/String.html" class="external">http://docs.ruby-lang.org/en/2.3.0/String.html</a> is good example. Almost every modifier method has safe and dangerous counterpart (instead some methods like insert, prepend, replace, concat).<br>
This was i think good predisposition to implement immutable strings. Because there exists methods which modify data and returns new one. Or when i don't want to use immutable strings, there are still dangerous methods.</p>
<p>I think this ideology how safe and dangerous methods works could be use wide across all language operations. Next major version is still so far away.</p> Ruby master - Feature #12637: Unified and consistent method naming for safe and dangerous methodshttps://bugs.ruby-lang.org/issues/12637?journal_id=598892016-08-03T03:55:00Ztrans (Thomas Sawyer)
<ul></ul><p>It would more interesting if there were a way to declare an object mutable or not, then when immutable destructive methods would not be available.</p> Ruby master - Feature #12637: Unified and consistent method naming for safe and dangerous methodshttps://bugs.ruby-lang.org/issues/12637?journal_id=598932016-08-03T05:20:47Zphluid61 (Matthew Kerwin)matthew@kerwin.net.au
<ul></ul><p>Thomas Sawyer wrote:</p>
<blockquote>
<p>It would more interesting if there were a way to declare an object mutable or not, then when immutable destructive methods would not be available.</p>
</blockquote>
<p>Do you mean #freeze ?</p> Ruby master - Feature #12637: Unified and consistent method naming for safe and dangerous methodshttps://bugs.ruby-lang.org/issues/12637?journal_id=600112016-08-09T08:48:07Zmatz (Yukihiro Matsumoto)matz@ruby.or.jp
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Rejected</i></li></ul><p>Ruby is not Scheme.</p>
<p>The rule is simple: every bang method should have its non-bang version, which does not modify the receiver.<br>
That does not mean every non-bang method keeps its receiver unchanged.</p>
<p>Matz.</p> Ruby master - Feature #12637: Unified and consistent method naming for safe and dangerous methodshttps://bugs.ruby-lang.org/issues/12637?journal_id=667922017-09-20T10:14:00Zr.smitala (Radovan Smitala)
<ul></ul><p>matz (Yukihiro Matsumoto) wrote:</p>
<blockquote>
<p>Ruby is not Scheme.</p>
<p>The rule is simple: every bang method should have its non-bang version, which does not modify the receiver.<br>
That does not mean every non-bang method keeps its receiver unchanged.</p>
<p>Matz.</p>
</blockquote>
<p>I know my reply could be annoying. I am apologise before.<br>
After a year of using Ruby in mid-sized project we had some unlikely issues with mutating receiver. Because we are influenced by functional principle immutability of object we fixing interesting behaviour of our app caused by our infallibility that code we used doesn't change the state. As we figuring out we have forgot that some methods changing the receiver.</p>
<p>By our experience it is easier to remember uniform behaviour (immutable/mutable) for method calling than thinking about different behaviour for some methods without bang alternative.<br>
we had no problem with remembering that Integer, Float, Nil, and Boolean is passed by value and everything else with reference. But method behaviour because we can't be sure that method without exclamation mark should return new value.</p>
<p>I also think migration to new method naming is really easy with simple regex replacing.</p> Ruby master - Feature #12637: Unified and consistent method naming for safe and dangerous methodshttps://bugs.ruby-lang.org/issues/12637?journal_id=668112017-09-21T04:40:04Zduerst (Martin Dürst)duerst@it.aoyama.ac.jp
<ul></ul><p>r.smitala (Radovan Smitala) wrote:</p>
<blockquote>
<p>I also think migration to new method naming is really easy with simple regex replacing.</p>
</blockquote>
<p>It's not so easy. There may be programs with variable names such as <code>fill</code>, user written classes with methods that have the same names as the ones you want to change, and so on.</p>
<p>And the more heavy cost is to change all the knowledge that all the current Ruby programmers already have.</p> Ruby master - Feature #12637: Unified and consistent method naming for safe and dangerous methodshttps://bugs.ruby-lang.org/issues/12637?journal_id=668132017-09-21T07:25:40Zr.smitala (Radovan Smitala)
<ul></ul><p>duerst (Martin Dürst) wrote:</p>
<blockquote>
<p>r.smitala (Radovan Smitala) wrote:</p>
<blockquote>
<p>I also think migration to new method naming is really easy with simple regex replacing.</p>
</blockquote>
<p>It's not so easy. There may be programs with variable names such as <code>fill</code>, user written classes with methods that have the same names as the ones you want to change, and so on.</p>
</blockquote>
<p>You are right about migration. I don't count all variations of method using.</p>
<blockquote>
<p>And the more heavy cost is to change all the knowledge that all the current Ruby programmers already have.</p>
</blockquote>
<p>I think it is why Ruby popularity stagnatess or slightly decreases. No new blood or just little comes to community. Community getting older. Many went to another languages like Elixir not because they are fancy and new but i think because they are easier to learn and remember how they works. No different behaviour in whole language. Eg immutable, we no need to care about function behaviour. Everytimes it return new instance. And this is great. Uniformity.</p>
<p>Things like pattern matching or pipe operator are just syntactic sugar. It could be added anytime. But adapt language to new needs is required to make this language live in future.</p>
<p>Ruby is great language, i using it in my professional career for 8 years. Ruby's power it is human friendly universal language. Anyone can use it in imperative or functional way. And this is great opportunity to be bigger and more future-proof. But i think Ruby suffer for it's legacy. It was created in different age with different needs.<br>
Ruby is preparing for great version 3. Isn't this option how to change some things?</p>
<p>For example global string freezing. How about this code?<br>
<code>"hello".concat("world")</code><br>
will this code works with global string freezing anyway or it return exception?</p>
<p>If it return exemption or return new string instance it is change on fundamental behaviour, because in documentation this method change receiver. In both ways old code will not work.</p>
<p>I really like to see safe methods and dangerous methods cross all language.<br>
If i use <code>"hello".concat("world")</code> or <code>"hello" << "world"</code> i will know it returns new instance. But if i use alternative with examation mark/bang i know it changes it receiver (eg unfreeze string and write into same variable name).</p>
<p>Isn't it easier to remember or to read by another developer?<br>
Ruby influence many languages like Elixir or Crystal. They use similar syntax because it is strong advantage of Ruby, but they remove all ambiguity and it is their strong advantage, but not for Ruby at this age.</p>
<p>But as i use different languages more and more i miss some principles or functions in Ruby.<br>
Like spread operator for hash {...anotherObject}, better asynchronous syntax (async await), uniform behaviour cross all language (always new value), pipe operator etc.</p>
<p>Modified and added:</p>
<p>Ruby doesn't have corporate background like C#, Java or Swift or is not only language in field like JavaScript. If we like it or not Ruby is just another language. People want new features, if Ruby doesn't deliver it they will leave.</p>