https://bugs.ruby-lang.org/https://bugs.ruby-lang.org/favicon.ico?17113305112018-09-21T19:28:51ZRuby Issue Tracking SystemRuby master - Feature #15145: chained mappings proposalhttps://bugs.ruby-lang.org/issues/15145?journal_id=741412018-09-21T19:28:51Zkoenhandekyn (koen handekyn)
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/74141/diff?detail_id=49924">diff</a>)</li></ul> Ruby master - Feature #15145: chained mappings proposalhttps://bugs.ruby-lang.org/issues/15145?journal_id=741422018-09-21T22:51:58Zshevegen (Robert A. Heiler)shevegen@gmail.com
<ul></ul><p>(I think you filed this in the wrong section; right now it is under Bugs, but it looks<br>
like a feature so it should go into<br>
<a href="https://bugs.ruby-lang.org/projects/ruby-trunk/issues?set_filter=1&tracker_id=2" class="external">https://bugs.ruby-lang.org/projects/ruby-trunk/issues?set_filter=1&tracker_id=2</a> )</p>
<p>At any rate, to the suggestion itself:</p>
<p>I am already biased because I am not a big fan of object&.method for various reasons,<br>
some of which are a personal preference (but also because my eyesight is not the best).</p>
<p>However had, you don't have to convince me - you ultimately only have to convince<br>
matz (and it helps to convince the core team too).</p>
<p>Aside from any personal bias, I think there may be more objective reasons against the<br>
proposal from a syntax and "meaning" point of view.</p>
<p>I may be mistaken, but I believe</p>
<pre><code>collection.map(&:instrument)
</code></pre>
<p>always meant a to_proc call (e. g. <a href="https://stackoverflow.com/a/8793693/722915" class="external">https://stackoverflow.com/a/8793693/722915</a> ).</p>
<p>This was probably also one reason why it could not too easily be extended to<br>
also allow for arguments passed into it, e. g. anything where you<br>
pass stuff into the method that is called there.</p>
<p>Having object.map(&:foo) suddenly mean object.map { |e| e&.foo } is, I think,<br>
re-defining existing behaviour. Perhaps there are cases where this new behaviour<br>
would be undesired? But I may be wrong; I make use of & only very sparingly<br>
so in the ruby code I write/use.</p>
<p>Aside from this, the net gain seems to be fairly small.</p>
<p>I understand succinctness being a good thing usually but I don't really see any<br>
real net gain here.</p>
<p>As for intermediate nil values - to be honest I think it is possible to design<br>
methods in such a way as to act as a filter, and discard nil values when they<br>
are not necessary to begin with (e. g. making more use of .compact). But as<br>
written above, you ultimately have to only convince matz. You can suggest to<br>
add it to the next developer discussion to get the opinion(s) of the core<br>
devs if you would like to, at:</p>
<p><a href="https://bugs.ruby-lang.org/issues/15129" class="external">https://bugs.ruby-lang.org/issues/15129</a></p> Ruby master - Feature #15145: chained mappings proposalhttps://bugs.ruby-lang.org/issues/15145?journal_id=741442018-09-22T00:06:18Zjeremyevans0 (Jeremy Evans)merch-redmine@jeremyevans.net
<ul><li><strong>Tracker</strong> changed from <i>Bug</i> to <i>Feature</i></li><li><strong>Backport</strong> deleted (<del><i>2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN</i></del>)</li></ul><p>koenhandekyn (koen handekyn) wrote:</p>
<blockquote>
<p>proposal allow</p>
<pre><code class="ruby syntaxhl" data-language="ruby"><span class="n">collection</span><span class="p">.</span><span class="nf">map</span><span class="p">(</span><span class="o">&</span><span class="ss">:instrument</span><span class="p">,</span> <span class="o">&</span><span class="ss">:issuer</span><span class="p">,</span> <span class="o">&</span><span class="ss">:name</span><span class="p">)</span>
</code></pre>
<p>implementation is trivial</p>
</blockquote>
<p>Is it possible for you to share your trivial implementation of passing more than one block to a method? :)</p>
<p>It is true that the implementation of something like:</p>
<pre><code class="ruby syntaxhl" data-language="ruby"><span class="n">collection</span><span class="p">.</span><span class="nf">chained_map</span><span class="p">(</span><span class="ss">:instrument</span><span class="p">.</span><span class="nf">to_proc</span><span class="p">,</span> <span class="ss">:issuer</span><span class="p">.</span><span class="nf">to_proc</span><span class="p">,</span> <span class="ss">:name</span><span class="p">.</span><span class="nf">to_proc</span><span class="p">)</span>
</code></pre>
<p>is fairly trivial, but it could easily be added via an external gem. I don't think it makes sense to add a <code>Enumerable#chained_map</code> core method or to modify the <code>Enumerable#map</code> core method to accept arguments. And I think adding the ability for a method to accept multiple blocks would be another feature request entirely.</p>
<p>In my opinion, it would probably be clearer to just use <code>map</code> with a single block:</p>
<pre><code class="ruby syntaxhl" data-language="ruby"><span class="n">collection</span><span class="p">.</span><span class="nf">map</span> <span class="p">{</span> <span class="o">|</span><span class="n">e</span><span class="o">|</span> <span class="n">e</span><span class="o">&</span><span class="p">.</span><span class="nf">instrument</span><span class="o">&</span><span class="p">.</span><span class="nf">issuer</span><span class="o">&</span><span class="p">.</span><span class="nf">name</span> <span class="p">}</span>
</code></pre>