https://redmine.ruby-lang.org/https://redmine.ruby-lang.org/favicon.ico?17113305112019-08-23T15:36:41ZRuby Issue Tracking SystemRuby master - Feature #16120: Omitted block argument if block starts with dot-method callhttps://redmine.ruby-lang.org/issues/16120?journal_id=809392019-08-23T15:36:41Zosyo (manga osyo)
<ul></ul><p>hi.<br>
Its soo good idea.<br>
However, I think it is difficult to parse in the following cases.</p>
<pre><code class="ruby syntaxhl" data-language="ruby"><span class="p">[</span><span class="mi">10</span><span class="p">,</span> <span class="mi">20</span><span class="p">,</span> <span class="mi">30</span><span class="p">].</span><span class="nf">map</span><span class="p">{</span>
<span class="c1"># 42.to_s(16)</span>
<span class="c1"># or</span>
<span class="c1"># pp 42</span>
<span class="c1"># argument1.to_s(16)</span>
<span class="n">pp</span> <span class="mi">42</span>
<span class="p">.</span><span class="nf">to_s</span><span class="p">(</span><span class="mi">16</span><span class="p">)</span>
<span class="p">}</span>
</code></pre> Ruby master - Feature #16120: Omitted block argument if block starts with dot-method callhttps://redmine.ruby-lang.org/issues/16120?journal_id=809522019-08-23T23:42:23Zshan (Shannon Skipper)
<ul></ul><p>A bit of an aside, but it's often just as fast to do two iterations with small collections, since the shorthand parses faster.</p>
<pre><code>posts.map(&:author).map(&:name)
</code></pre>
<p>I agree with osyo that it seems this proposal collides with existing parser behavior. It would introduce incompatibility.</p> Ruby master - Feature #16120: Omitted block argument if block starts with dot-method callhttps://redmine.ruby-lang.org/issues/16120?journal_id=809552019-08-24T00:59:52ZDan0042 (Daniel DeLorme)
<ul></ul><p>I think there's a misunderstanding because this proposal doesn't collide with existing parser behavior. <code>[].each{ .method }</code> is currently a SyntaxError.</p>
<p><a class="user active user-mention" href="https://redmine.ruby-lang.org/users/13476">@osyo (manga osyo)</a> wrote:</p>
<blockquote>
<p>However, I think it is difficult to parse in the following cases.</p>
</blockquote>
<p>It parses just like this:</p>
<pre><code class="ruby syntaxhl" data-language="ruby"><span class="p">[</span><span class="mi">10</span><span class="p">,</span> <span class="mi">20</span><span class="p">,</span> <span class="mi">30</span><span class="p">].</span><span class="nf">map</span><span class="p">{</span> <span class="o">|</span><span class="n">v</span><span class="o">|</span> <span class="n">v</span>
<span class="n">pp</span> <span class="mi">42</span>
<span class="p">.</span><span class="nf">to_s</span><span class="p">(</span><span class="mi">16</span><span class="p">)</span>
<span class="p">}</span>
</code></pre>
<p>In other words the block argument is not used, and <code>.to_s(16)</code> applies to <code>42</code>, just like regular method chaining.</p> Ruby master - Feature #16120: Omitted block argument if block starts with dot-method callhttps://redmine.ruby-lang.org/issues/16120?journal_id=809562019-08-24T01:07:06ZDan0042 (Daniel DeLorme)
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/80956/diff?detail_id=54478">diff</a>)</li></ul> Ruby master - Feature #16120: Omitted block argument if block starts with dot-method callhttps://redmine.ruby-lang.org/issues/16120?journal_id=809572019-08-24T01:57:41Zmame (Yusuke Endoh)mame@ruby-lang.org
<ul></ul><p>Hi,</p>
<blockquote>
<p>So I strongly believe all these feature requests should to be considered together in order to make a decision.</p>
</blockquote>
<p>Agreed. And, <a class="issue tracker-5 status-7 priority-4 priority-default closed" title="Misc: Reconsider numbered parameters (Feedback)" href="https://redmine.ruby-lang.org/issues/15723">#15723</a> (a numbered parameter) is only one proposal that is all-purpose, though I don't like it so much.</p>
<blockquote>
<p>A shorthand notation is less needed for { |x| foo(x) } since the two x variables are further apart and don't feel so redundant.</p>
</blockquote>
<p>I personally agree. I don't think that the variable name is redundant. But people seem to think so. Actually, a shorthand for Object#method is planned for 2.7 (<a class="issue tracker-2 status-1 priority-4 priority-default" title="Feature: Proposal: Shorthand operator for Object#method (Open)" href="https://redmine.ruby-lang.org/issues/12125">#12125</a>), and I hear many people want to use it as: <code>map(&JSON.:parse)</code>. The syntax you propose cannot absorb this style.</p> Ruby master - Feature #16120: Omitted block argument if block starts with dot-method callhttps://redmine.ruby-lang.org/issues/16120?journal_id=810552019-08-26T19:34:03ZDan0042 (Daniel DeLorme)
<ul></ul><p>The syntax I propose is definitely not <em>meant</em> to absorb all styles. I think any attempt to be everything to everyone is doomed to failure. I do not believe this is a race where only one of the various proposals can win; considering the various proposals together means finding the right balance, not finding a single all-purpose solution.</p>
<p>In fact I find that <code>map{ .to_s(16) }</code> and <code>map(&JSON.:parse)</code> are very complementary...</p>
<ul>
<li>
<code>map{ .to_s(16) }</code> is shorthand for <code>map{ |x| x.to_s(16) }</code>; each element is the receiver of a message; this is OO style. I would use that a lot.</li>
<li>
<code>map(&JSON.:parse)</code> is shorthand for <code>map{ |x| JSON.parse(x) }</code>; each element is the argument of a function; this is functional style, for people who want first-class functions in ruby. I would likely never use that. But I don't mind others who want to use that style.</li>
</ul> Ruby master - Feature #16120: Omitted block argument if block starts with dot-method callhttps://redmine.ruby-lang.org/issues/16120?journal_id=810672019-08-26T23:49:38Zmame (Yusuke Endoh)mame@ruby-lang.org
<ul></ul><p>I believe that <code>map(&JSON.:parse)</code> must be considered together because it is strongly related to the motivation of your proposal. Note that <code>map(&JSON.:parse)</code> is incomplete. People will next want to omit a parameter of <code>map {|x| JSON.parse(x, symbolize_names: true) }</code>. The game is not ended, and the next proposal will definitely come, like <code>map(&JSON.:parse.(_, symbolize_names: true))</code> or what not. Only the numbered parameter can end the game.</p> Ruby master - Feature #16120: Omitted block argument if block starts with dot-method callhttps://redmine.ruby-lang.org/issues/16120?journal_id=810692019-08-27T00:18:24Znobu (Nobuyoshi Nakada)nobu@ruby-lang.org
<ul></ul><p><a href="https://github.com/nobu/ruby/tree/feature/implicit-block-param" class="external">https://github.com/nobu/ruby/tree/feature/implicit-block-param</a></p> Ruby master - Feature #16120: Omitted block argument if block starts with dot-method callhttps://redmine.ruby-lang.org/issues/16120?journal_id=810702019-08-27T01:39:17ZDan0042 (Daniel DeLorme)
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/81070/diff?detail_id=54578">diff</a>)</li></ul><p><a class="user active user-mention" href="https://redmine.ruby-lang.org/users/18">@mame (Yusuke Endoh)</a>, The motivation of <em>this</em> proposal is related to the <strong>side-by-side</strong> proximity/repetition of <code>x</code> in <code>{|x|x.foo}</code>. Other proposals may be different. I can only guess at their true motivations. It just <em>seems</em> to me that the people asking for that kind of shorthand really intend to use it for <code>{|x|x.foo}</code> and just throw in <code>{|x|foo(x)}</code> because why not. But <code>@</code> is similar to <code>$_</code> in that it's only useful for debugging or throwaway code. <code>{.foo}</code> can actually be used in production code and make it clearer.</p>
<p>The motivation for <code>(&JSON.:parse)</code>... honestly it seems like it's an entirely different beast. I don't think it's only about shortening the block. I have the feeling it's really about functional programming, and that <code>{JSON.parse(@)}</code> would not satistify the "requirement" for first-class functions. This one seems to be more about function composition, currying and whatnot, and less about avoiding verbosity.</p>
<p>You make a painfully good point about how unendingly persistent these proposals are. But if the numbered parameter could really end the game, I'm quite sure there would not be so much opposition to it in <a class="issue tracker-5 status-7 priority-4 priority-default closed" title="Misc: Reconsider numbered parameters (Feedback)" href="https://redmine.ruby-lang.org/issues/15723">#15723</a>.</p> Ruby master - Feature #16120: Omitted block argument if block starts with dot-method callhttps://redmine.ruby-lang.org/issues/16120?journal_id=810712019-08-27T02:16:22Zjeremyevans0 (Jeremy Evans)merch-redmine@jeremyevans.net
<ul></ul><p>Dan0042 (Daniel DeLorme) wrote:</p>
<blockquote>
<p><a class="user active user-mention" href="https://redmine.ruby-lang.org/users/18">@mame (Yusuke Endoh)</a>, The motivation of <em>this</em> proposal is related to the <strong>side-by-side</strong> proximity/repetition of <code>x</code> in <code>{|x|x.foo}</code>. Other proposals may be different. I can only guess at their true motivations. It just <em>seems</em> to me that the people asking for that kind of shorthand really intend to use it for <code>{|x|x.foo}</code> and just throw in <code>{|x|foo(x)}</code> because why not. But <code>@</code> is similar to <code>$_</code> in that it's only useful for debugging or throwaway code. <code>{.foo}</code> can actually be used in production code and make it clearer.</p>
</blockquote>
<p>I disagree. <code>{ foo(@) }</code> and <code>{ @.foo }</code> are not for debugging or throwaway code, they are natural replacements for <code>{ |x| foo(x) }</code> and <code>{|x| x.foo }</code>. The <code>@</code> single implicit parameter approach is just as clear and is significantly more flexible than this approach (lacking a better name, the omitted parameter approach).</p>
<p>That's not to say the omitted parameter approach is bad. In the cases it does handle, it does save a character compared to the implicit parameter approach. I don't think that character saving makes the code clearer than the single implicit parameter approach, though. In my opinion they are even in terms of clarity.</p>
<blockquote>
<p>The motivation for <code>(&JSON.:parse)</code>... honestly it seems like it's an entirely different beast. I don't think it's only about shortening the block. I have the feeling it's really about functional programming, and that <code>{JSON.parse(@)}</code> would not satistify the "requirement" for first-class functions. This one seems to be more about function composition, currying and whatnot, and less about avoiding verbosity.</p>
</blockquote>
<p>I think the implicit parameter approach (<code>{JSON.parse(@)}</code>) is a simpler and more readable approach than the dot-colon approach (<code>(&JSON.:parse)</code>). Especially when you start function composition (<code>{JSON.parse(JSON.generate(@))}</code> vs <code>(&(JSON.:parse << JSON.:generate))</code>). Especially when you consider things like additional block arguments and keyword arguments (<code>:symbolize_keys</code>) passed to the methods.</p>
<blockquote>
<p>You make a painfully good point about how unendingly persistent these proposals are. But if the numbered parameter could really end the game, I'm quite sure there would not be so much opposition to it in <a class="issue tracker-5 status-7 priority-4 priority-default closed" title="Misc: Reconsider numbered parameters (Feedback)" href="https://redmine.ruby-lang.org/issues/15723">#15723</a>.</p>
</blockquote>
<p>By "end the game", I think mame means that it is the most flexible approach, not necessarily the best approach. And it doesn't really "end the game", as it doesn't handle block or keyword arguments :).</p> Ruby master - Feature #16120: Omitted block argument if block starts with dot-method callhttps://redmine.ruby-lang.org/issues/16120?journal_id=810862019-08-27T14:43:23ZDan0042 (Daniel DeLorme)
<ul><li><strong>Subject</strong> changed from <i>Implicit block argument if block starts with dot-method call</i> to <i>Omitted block argument if block starts with dot-method call</i></li><li><strong>Description</strong> updated (<a title="View differences" href="/journals/81086/diff?detail_id=54590">diff</a>)</li></ul><p><a class="user active user-mention" href="https://redmine.ruby-lang.org/users/4">@nobu (Nobuyoshi Nakada)</a>, wow, thank you so much. I never imagined it would be THAT simple to implement.<br>
<code>O_O @_@ m(_ _)m</code></p>
<p>But I do think it would be better with <code>(parser_numbered_param(p, 0))</code> in the commit <a href="https://github.com/ruby/ruby/commit/7d14171d959f4088b04ca892cb36472171fa01e9" class="external">here</a> <code>m(_ _)m</code></p>
<hr>
<p>jeremyevans0 (Jeremy Evans) wrote:</p>
<blockquote>
<p>In the cases it does handle, it does save a character compared to the implicit parameter approach. I don't think that character saving makes the code clearer than the single implicit parameter approach, though. In my opinion they are even in terms of clarity.</p>
</blockquote>
<p>I totally agree that "saving" a single character makes no difference. But all these proposals are not about reducing mere character count, they're about reducing... I don't know the right word... cognitive complexity? lexical redundancy? conceptual overhead? It's the reason why people propose <code>{item.foo}</code> even though it has <em>zero</em> characters less than <code>{|x|x.foo}</code>. It's the reason why people who use nice descriptive variable and method names can also propose <code>{@.foo}</code> even though it's an insignificant three character saving. It's the reason why human languages use omissions and pronouns. Allow me to make a comparison with english:</p>
<pre><code>omitted {.foo} John went to the market and bought apples
implicit {@.foo} John went to the market and he bought apples
numbered {@1.foo} John went to the market and HE bought apples
explicit {|x|x.foo} John went to the market and John bought apples
</code></pre>
<p>There's a reason why the first form is the most natural. When people talk about a block shorthand, I really think they mean shorter in the sense of cognition, not character count (although the two are somewhat related). So rather than thinking of a 1-char saving, it's more like explicit has 2x overhead, implicit has 1x, and omitted has 0x. Yes, we're talking about a very very tiny amount of overhead, I'll grant you, but enough to have these proposals keep popping up. That's not to say the implicit parameter approach is bad, in fact I rather like it. I just happen to think the omitted approach has so much better "flow". 1x/0x = Infinity kind of thing.</p>
<blockquote>
<p>I think the implicit parameter approach (<code>{JSON.parse(@)}</code>) is a simpler and more readable approach than the dot-colon approach (<code>(&JSON.:parse)</code>).</p>
</blockquote>
<p>I totally agree there again. I was trying to present the perspective of functional-style first-class-function people (which I am not). Maybe trying to argue on behalf of others is a mistake in itself.</p> Ruby master - Feature #16120: Omitted block argument if block starts with dot-method callhttps://redmine.ruby-lang.org/issues/16120?journal_id=810882019-08-27T15:13:04ZHanmac (Hans Mackowiak)hanmac@gmx.de
<ul></ul><p><a class="user active user-mention" href="https://redmine.ruby-lang.org/users/11019">@Dan0042 (Daniel DeLorme)</a> in your list about implicit and explicit you forgot <code>{ foo }</code> depending on the method who gets the block, it might does an instance_eval thing where the block self is the block variable</p>
<p>i know that would need to change of the method, but this one might be possible too</p> Ruby master - Feature #16120: Omitted block argument if block starts with dot-method callhttps://redmine.ruby-lang.org/issues/16120?journal_id=811962019-08-27T17:25:34ZDan0042 (Daniel DeLorme)
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/81196/diff?detail_id=54902">diff</a>)</li></ul> Ruby master - Feature #16120: Omitted block argument if block starts with dot-method callhttps://redmine.ruby-lang.org/issues/16120?journal_id=811972019-08-27T17:36:57ZDan0042 (Daniel DeLorme)
<ul></ul><p>Hanmac (Hans Mackowiak) wrote:</p>
<blockquote>
<p><a class="user active user-mention" href="https://redmine.ruby-lang.org/users/11019">@Dan0042 (Daniel DeLorme)</a> in your list about implicit and explicit you forgot <code>{ foo }</code> depending on the method who gets the block, it might does an instance_eval thing where the block self is the block variable</p>
</blockquote>
<p>There was something like that in <a class="issue tracker-2 status-7 priority-4 priority-default closed" title="Feature: An instance method on Enumerator that evaluates the block under with self being the block variable. (Feedback)" href="https://redmine.ruby-lang.org/issues/10394">#10394</a>, but I think it changes the semantics of the block too much. Should <code>{foo(bar)}</code> really be equivalent to <code>{|v|v.foo(v.bar)}</code> ? I don't think so.</p> Ruby master - Feature #16120: Omitted block argument if block starts with dot-method callhttps://redmine.ruby-lang.org/issues/16120?journal_id=816262019-09-20T07:22:23Zshevegen (Robert A. Heiler)shevegen@gmail.com
<ul></ul><p>The idea is very interesting to me, purely from a conceptual point of view<br>
alone. So from this point of view, I like the idea itself, or the thoughts<br>
behind the idea.</p>
<p>HOWEVER had, at the same time, I actually dislike the syntax.</p>
<p>My brain wants to associate the ".something" method call with some specific<br>
object, and in the proposal we would then have a situation where the method<br>
invocation is not directly attached to an object. Again, I understand the<br>
intent, but I dislike it from a syntax point of view.</p>
<blockquote>
<p>In a way it's similar to chaining methods on multiple lines:</p>
</blockquote>
<pre><code>posts.map{ |post| post
.author.name
}
</code></pre>
<p>Yes, I get the intent, but it is not really similar in this sense; it is<br>
actually different because we would then be allowed to omit the reference<br>
to the object "magically".</p>
<p>So if I were to have a say, my personal opinion is -1 on the proposal as<br>
such, even though oddly enough I also like it at the same time (that has<br>
not happened often before where I was against something even though<br>
liking it in some ways).</p>
<p>Jeremy wrote:</p>
<blockquote>
<p>I totally agree that "saving" a single character makes no difference.</p>
</blockquote>
<p>In the context of e. g. numbered parameters, I agree. But when it comes<br>
to Symbols versus Strings, to me the single character matters a lot. :-)</p>
<p>I understand that this has not been why matz added Symbols, but I like<br>
them and use them a lot, even simply as shortcut "identifier" in<br>
method colours e. g:</p>
<pre><code>disable :colours
</code></pre>
<p>(It's actually convenient to me more generally than e. g. passing a<br>
'string', even though symbols and strings have a different<br>
meaning/purpose.)</p>
<blockquote>
<p>You could have [1,2,3].map{ .itself + @ + @1 }</p>
</blockquote>
<p>Now I happily admit that I dislike itself, but I think I dislike<br>
it even more in a .itself variant, together with @ and @1. Actually,<br>
@1 is better than @. I think @ alone is actually the worst here.</p>
<p>But we should not really tie a suggestion such as this one here<br>
to other not-directly related suggestions such as numbered parameter.<br>
(I think matz went for another syntax meanwhile, so suggestions<br>
may become outdated, too. :))</p>
<p>I agree that:</p>
<pre><code>posts.map{ .author.name }
</code></pre>
<p>is, oddly enough, very readable. I like that part. Still I am against<br>
it; I completely understand it where we may refer to whatever is<br>
"held" inside the block, but I don't like free floating method calls<br>
in ruby code to be honest.</p>
<p>Last but not least about numbered paramaters; I bring this due to the<br>
brief discussion about between mame and jeremy.</p>
<p>I think people will always focus about different parts about numbered<br>
parameters. For me the biggest advantage is that we can quickly use<br>
it to debug longer "data structures" without having to remember the<br>
name as-is. I don't think I want it to remain in my own code though,<br>
since it is not super-elegant; on the other hand I am also fine with<br>
it being in code, in principle. But this opinion does not seem to be<br>
the one that you can read most often. People either love it, or<br>
hate it; sort of. It's strange to me. :-)</p>
<p>Even then I think one last thing should not be forgotten about ALL<br>
changes to ruby in the last ~3 or 4 years or so - specific changes<br>
were made that gave new options. Even though I myself dislike the<br>
syntax part of some suggestions, or my poor eye sight in regards<br>
to object.:method, we should include the possibility of new features<br>
leading to scenarios where less code (or simpler code) might be<br>
use; a good example for that is the safe navigation / lonely<br>
person staring at a dot, change.</p> Ruby master - Feature #16120: Omitted block argument if block starts with dot-method callhttps://redmine.ruby-lang.org/issues/16120?journal_id=816752019-09-23T17:05:41ZDan0042 (Daniel DeLorme)
<ul></ul><p>Since I wasn't at the developer meeting I'll post my thoughts/responses to the log here.</p>
<blockquote>
<p>matz: I prefer this style to .map(&:to_s). But I understand it is not flexible enough. Difficult to determine.</p>
</blockquote>
<p>This shorthand simplifies one of the most common block idioms, no more no less (dotadiw). IMHO it's meant to be elegant rather than flexible; for flexibility one should always use the regular block syntax.</p>
<blockquote>
<p>shevegen: if I were to have a say, my personal opinion is -1 on the proposal as such, even though oddly enough I also like it at the same time</p>
</blockquote>
<p>That's... an interesting paradox. I would say to you (and matz): just trust your gut feeling on this and accept that it "looks really nice" without overanalyzing :-)</p>
<blockquote>
<p>mame: If this style is accepted, Symbol#to_proc is deprecated? It sounds good.<br>
matz: Sounds like a plan.</p>
</blockquote>
<p>I'm pretty sure everyone will voluntarily switch from <code>(&:to_s)</code> to <code>{.to_s}</code> but even so is there really a need to go so far as to deprecate Symbol#to_proc ?</p>
<blockquote>
<p>someone: Can we write 1.times { .foo; any-statement }?<br>
matz: No</p>
</blockquote>
<p>I have no idea why someone would want to write this, but why is there a need to disallow it? The shorthand is simpler to explain and implement if it's just <code>{.foo</code> is equivalent to <code>{|x|x.foo</code>, without special exceptions or restrictions to account for.</p>
<blockquote>
<p>nobu: It is difficult to implement… Currently my patch even allows 1.times { .foo(.bar) }<br>
matz: No</p>
</blockquote>
<p>Wow, I did not realize your patch allowed that! I think it's safer if it's only at the beginning of the block. I've tried writing a patch for that. Please forgive if it's too hacky. <del><a href="https://github.com/dan42/ruby/commit/51e5fa4d4a56c29e5f0ceb1e5544822e9215148f" class="external">https://github.com/dan42/ruby/commit/51e5fa4d4a56c29e5f0ceb1e5544822e9215148f</a></del><br>
Much better now: <a href="https://github.com/dan42/ruby/commit/09c49f36d65338a8a2d5f0c1f1d8e41e734eacc2" class="external">https://github.com/dan42/ruby/commit/09c49f36d65338a8a2d5f0c1f1d8e41e734eacc2</a> (It still crashes Ripper though)</p> Ruby master - Feature #16120: Omitted block argument if block starts with dot-method callhttps://redmine.ruby-lang.org/issues/16120?journal_id=817012019-09-24T22:08:16ZDan0042 (Daniel DeLorme)
<ul></ul><p>I ended up rebasing my commits to the latest master and then fiddling with parse.y until I got everything clean and working, including Ripper.<br>
So this is my implementation of omitted parameters based on nobu's original patch:<br>
<a href="https://github.com/dan42/ruby/commit/62628cb739748bcca2297c8aaec1195d7565f100" class="external">https://github.com/dan42/ruby/commit/62628cb739748bcca2297c8aaec1195d7565f100</a></p> Ruby master - Feature #16120: Omitted block argument if block starts with dot-method callhttps://redmine.ruby-lang.org/issues/16120?journal_id=820762019-10-16T15:58:36ZDan0042 (Daniel DeLorme)
<ul></ul><p>Rebased my patch to the latest master and cleaned up the code a bit:<br>
<a href="https://github.com/dan42/ruby/commit/11f609af003370396d0e82381b57ea5a73ff6d8a" class="external">https://github.com/dan42/ruby/commit/11f609af003370396d0e82381b57ea5a73ff6d8a</a></p> Ruby master - Feature #16120: Omitted block argument if block starts with dot-method callhttps://redmine.ruby-lang.org/issues/16120?journal_id=821032019-10-17T08:42:00Zmatz (Yukihiro Matsumoto)matz@ruby.or.jp
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Rejected</i></li></ul><p>After reconsideration, I came to the conclusion that we should use numbered parameters instead of this feature.<br>
Thank you for a pretty interesting idea. It was good food for thought.</p>
<p>Matz.</p> Ruby master - Feature #16120: Omitted block argument if block starts with dot-method callhttps://redmine.ruby-lang.org/issues/16120?journal_id=821062019-10-17T13:27:56ZDan0042 (Daniel DeLorme)
<ul></ul><p>I am so sad :-(</p>
<p>I was really looking forward to using this beautiful syntax instead of numbered parameters which I find so ugly I prefer to use an explicit block variable.</p>
<p>Am I the only one who thinks the omitted parameter is by far the most DRY and readable in these examples? imho, omitted > explicit > numbered</p>
<pre><code class="ruby syntaxhl" data-language="ruby"><span class="n">posts</span><span class="p">.</span><span class="nf">map</span><span class="p">{</span> <span class="o">|</span><span class="nb">p</span><span class="o">|</span> <span class="nb">p</span><span class="p">.</span><span class="nf">author</span><span class="p">.</span><span class="nf">name</span> <span class="p">}</span> <span class="c1">#explicit looks kinda ugly (for this case) so I want to simplify it</span>
<span class="n">posts</span><span class="p">.</span><span class="nf">map</span><span class="p">{</span> <span class="n">_1</span><span class="p">.</span><span class="nf">author</span><span class="p">.</span><span class="nf">name</span> <span class="p">}</span> <span class="c1">#numbered is even uglier</span>
<span class="n">posts</span><span class="p">.</span><span class="nf">map</span><span class="p">{</span> <span class="p">.</span><span class="nf">author</span><span class="p">.</span><span class="nf">name</span> <span class="p">}</span> <span class="c1">#omitted is beautiful</span>
<span class="n">posts</span><span class="p">.</span><span class="nf">map</span><span class="p">{</span> <span class="o">|</span><span class="nb">p</span><span class="o">|</span> <span class="n">format_author_name_as_html</span><span class="p">(</span><span class="nb">p</span><span class="p">)</span> <span class="p">}</span> <span class="c1">#this looks fine, I don't feel a need to simplify it</span>
<span class="n">posts</span><span class="p">.</span><span class="nf">map</span><span class="p">{</span> <span class="n">format_author_name_as_html</span><span class="p">(</span><span class="n">_1</span><span class="p">)</span> <span class="p">}</span> <span class="c1">#just as I thought, this looks worse</span>
<span class="n">array3D</span> <span class="n">array3D</span> <span class="n">array3D</span>
<span class="p">.</span><span class="nf">each</span> <span class="k">do</span> <span class="o">|</span><span class="n">array2D</span><span class="o">|</span> <span class="p">.</span><span class="nf">each</span> <span class="k">do</span> <span class="p">.</span><span class="nf">each</span> <span class="k">do</span>
<span class="n">array2D</span><span class="p">.</span><span class="nf">each</span> <span class="k">do</span> <span class="o">|</span><span class="n">array</span><span class="o">|</span> <span class="n">_1</span><span class="p">.</span><span class="nf">each</span> <span class="k">do</span> <span class="p">.</span><span class="nf">each</span> <span class="k">do</span>
<span class="n">array</span><span class="p">.</span><span class="nf">each</span> <span class="k">do</span> <span class="o">|</span><span class="n">point</span><span class="o">|</span> <span class="n">_1</span><span class="p">.</span><span class="nf">each</span> <span class="k">do</span> <span class="o">|</span><span class="n">point</span><span class="o">|</span> <span class="p">.</span><span class="nf">each</span> <span class="k">do</span> <span class="o">|</span><span class="n">point</span><span class="o">|</span>
<span class="c1">#^error</span>
</code></pre>
<p>I beg you to reconsider, for the beauty of ruby. m(_ _)m</p> Ruby master - Feature #16120: Omitted block argument if block starts with dot-method callhttps://redmine.ruby-lang.org/issues/16120?journal_id=821682019-10-18T07:01:40Znobu (Nobuyoshi Nakada)nobu@ruby-lang.org
<ul></ul><p>Dan0042 (Daniel DeLorme) wrote:</p>
<blockquote>
<pre><code class="ruby syntaxhl" data-language="ruby"><span class="n">posts</span><span class="p">.</span><span class="nf">map</span><span class="p">{</span> <span class="p">.</span><span class="nf">author</span><span class="p">.</span><span class="nf">name</span> <span class="p">}</span> <span class="c1">#omitted is beautiful</span>
</code></pre>
</blockquote>
<p>Sorry, it doesn't feel beautiful to me.</p>
<blockquote>
<pre><code class="ruby syntaxhl" data-language="ruby"><span class="n">array3D</span>
<span class="p">.</span><span class="nf">each</span> <span class="k">do</span>
<span class="p">.</span><span class="nf">each</span> <span class="k">do</span>
<span class="p">.</span><span class="nf">each</span> <span class="k">do</span> <span class="o">|</span><span class="n">point</span><span class="o">|</span>
</code></pre>
</blockquote>
<p>It looks confusing.</p> Ruby master - Feature #16120: Omitted block argument if block starts with dot-method callhttps://redmine.ruby-lang.org/issues/16120?journal_id=821702019-10-18T08:19:43Zdecuplet (Nikita Shilnikov)fg@flashgordon.ru
<ul></ul><p>Dan0042 (Daniel DeLorme) wrote:</p>
<blockquote>
<p>Am I the only one who thinks the omitted parameter is by far the most DRY and readable in these examples?</p>
</blockquote>
<p>Even if you are not, what does it change? Personally, I find this proposal interesting as an idea but I prefer <code>_1</code>, likely because of my familiarity with Clojure and Scala (it has a different meaning in Scala but nevertheless).</p> Ruby master - Feature #16120: Omitted block argument if block starts with dot-method callhttps://redmine.ruby-lang.org/issues/16120?journal_id=821712019-10-18T08:30:31ZHanmac (Hans Mackowiak)hanmac@gmx.de
<ul></ul><p>Dan0042 (Daniel DeLorme) wrote:</p>
<blockquote>
<pre><code class="ruby syntaxhl" data-language="ruby"><span class="n">array3D</span>
<span class="p">.</span><span class="nf">each</span> <span class="k">do</span>
<span class="p">.</span><span class="nf">each</span> <span class="k">do</span>
<span class="p">.</span><span class="nf">each</span> <span class="k">do</span> <span class="o">|</span><span class="n">point</span><span class="o">|</span>
</code></pre>
</blockquote>
<p>my main problem with omitting parameters there is that it can't know which binding you want to use?</p>
<p>i am already have problems with that because i think it should have used the outer scope</p>
<p>depending on the data structure shouldn't your array3D already have methods to iterate over points there? like an <code>each_point</code>?</p>