https://bugs.ruby-lang.org/https://bugs.ruby-lang.org/favicon.ico?17113305112019-11-20T13:11:13ZRuby Issue Tracking SystemRuby master - Feature #16356: Method#inspect of argument forwardinghttps://bugs.ruby-lang.org/issues/16356?journal_id=827402019-11-20T13:11:13Zznz (Kazuhiro NISHIYAMA)
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-5 priority-4 priority-default closed" href="/issues/14145">Feature #14145</a>: Proposal: Better Method#inspect</i> added</li></ul> Ruby master - Feature #16356: Method#inspect of argument forwardinghttps://bugs.ruby-lang.org/issues/16356?journal_id=827422019-11-20T20:11:29Zzverok (Victor Shepelev)zverok.offline@gmail.com
<ul></ul><p><code>#inspect</code> just follows whatever <code>#parameters</code> say.</p>
<p>But I indeed find that <code>#parameters</code> return value is kinda weird for this case:</p>
<pre><code>./ruby --disable-gems -e "def m(...); end; p method(:m).parameters"
[[:rest, :*], [:block, :&]]
</code></pre>
<p>E.g., literally, "parameter of the <em>type</em> <code>:rest</code>, <em>named</em> <code>*</code>, and parameter of the <em>type</em> <code>:block</code>, <em>named</em> <code>&</code>".</p>
<p>I believe that a proper return value for parameters in this case would be, probably</p>
<pre><code class="ruby syntaxhl" data-language="ruby"><span class="p">[[</span><span class="ss">:rest</span><span class="p">],</span> <span class="p">[</span><span class="ss">:keyrest</span><span class="p">],</span> <span class="p">[</span><span class="ss">:block</span><span class="p">]]</span>
</code></pre>
<p>If it would be so (and it seems reasonable), <code>#inspect</code> will return <code>#m(*, **, &)</code></p> Ruby master - Feature #16356: Method#inspect of argument forwardinghttps://bugs.ruby-lang.org/issues/16356?journal_id=827432019-11-20T20:30:59Zjeremyevans0 (Jeremy Evans)merch-redmine@jeremyevans.net
<ul></ul><p>zverok (Victor Shepelev) wrote:</p>
<blockquote>
<p><code>#inspect</code> just follows whatever <code>#parameters</code> say.</p>
<p>But I indeed find that <code>#parameters</code> return value is kinda weird for this case:</p>
<pre><code>./ruby --disable-gems -e "def m(...); end; p method(:m).parameters"
[[:rest, :*], [:block, :&]]
</code></pre>
<p>E.g., literally, "parameter of the <em>type</em> <code>:rest</code>, <em>named</em> <code>*</code>, and parameter of the <em>type</em> <code>:block</code>, <em>named</em> <code>&</code>".</p>
<p>I believe that a proper return value for parameters in this case would be, probably</p>
<pre><code class="ruby syntaxhl" data-language="ruby"><span class="p">[[</span><span class="ss">:rest</span><span class="p">],</span> <span class="p">[</span><span class="ss">:keyrest</span><span class="p">],</span> <span class="p">[</span><span class="ss">:block</span><span class="p">]]</span>
</code></pre>
<p>If it would be so (and it seems reasonable), <code>#inspect</code> will return <code>#m(*, **, &)</code></p>
</blockquote>
<p>That's not how <code>...</code> is implemented, though. It is implemented so that:</p>
<pre><code class="ruby syntaxhl" data-language="ruby"><span class="k">def</span> <span class="nf">a</span><span class="p">(</span><span class="o">...</span><span class="p">)</span>
<span class="n">b</span><span class="p">(</span><span class="o">...</span><span class="p">)</span>
<span class="k">end</span>
</code></pre>
<p>means</p>
<pre><code class="ruby syntaxhl" data-language="ruby"><span class="n">ruby2_keywords</span> <span class="k">def</span> <span class="nf">a</span><span class="p">(</span><span class="o">*</span><span class="n">args</span><span class="p">,</span> <span class="o">&</span><span class="n">block</span><span class="p">)</span>
<span class="n">b</span><span class="p">(</span><span class="o">*</span><span class="n">args</span><span class="p">,</span> <span class="o">&</span><span class="n">block</span><span class="p">)</span>
<span class="k">end</span>
</code></pre>
<p>other than the local variable names. So the current behavior omitting <code>:keyrest</code> makes sense. The local variable names should not be included, so the <code>parameters</code> output should probably be <code>[[:rest], [:block]]</code>.</p>
<p>This does raise a question of whether methods flagged with <code>ruby2_keywords</code> should have their <code>parameters</code> output reflect that. I'm not sure whether that is worth doing, but if so, we should probably replace <code>:rest</code> with something like <code>:restkw</code>.</p> Ruby master - Feature #16356: Method#inspect of argument forwardinghttps://bugs.ruby-lang.org/issues/16356?journal_id=827442019-11-20T20:58:44Zzverok (Victor Shepelev)zverok.offline@gmail.com
<ul></ul><p><a class="user active user-mention" href="https://bugs.ruby-lang.org/users/1604">@jeremyevans0 (Jeremy Evans)</a> thanks for the explanation, I suspected there is something important about missing <code>:keyrest</code> there :)<br>
But names (e.g. literal <code>:*</code> and <code>:&</code>) should be excluded from <code>parameters</code> output anyways, right?..</p> Ruby master - Feature #16356: Method#inspect of argument forwardinghttps://bugs.ruby-lang.org/issues/16356?journal_id=827472019-11-21T13:54:36Zshevegen (Robert A. Heiler)shevegen@gmail.com
<ul></ul><blockquote>
<p>But names (e.g. literal :* and :&) should be excluded from parameters output anyways, right?</p>
</blockquote>
<p>I am not matz, nor among the core team, but I think that the general intention is that the<br>
information displayed here (e. g. via #inspect) should be useful to the user, to some extent;<br>
and ideally consistent/uniform whenever possible.</p>
<p>As Kazuhiro showed, the display is like:</p>
<pre><code>#<Method: main.mf(**, &&) -e:1>
</code></pre>
<p>And I am not sure if this is that helpful for ruby users. It is also a bit strange that<br>
-e:1 is passed. I can not imagine that this is very useful to anyone. :) This is from<br>
the commandline, yes? I remember having that sometimes when invoking ruby scripts or<br>
e. g. calling a custom method in some .rb file.</p>
<p>So, no matter whether there may be reasons behind the display, I think Kazuhiro's question<br>
is a good one either way how you look at this. (Actually what may be missing in the<br>
issue description is to say what should otherwise be shown, rather than the current<br>
"main.mf(**, &&) -e:1". I guess one could also show more information if wanted or<br>
necessary, such as to indicate that it may be a forwarded-message. Perhaps matz or<br>
nobu may know what might fit best here.)</p>
<blockquote>
<p>So the current behavior omitting :keyrest makes sense.</p>
</blockquote>
<p>I think this is only one part; the other is whether this is very useful for ruby<br>
users. Kazuhiro did not explicitely mention this, but I think the current display<br>
is a bit weird.</p>