https://bugs.ruby-lang.org/https://bugs.ruby-lang.org/favicon.ico?17113305112016-02-05T03:22:29ZRuby Issue Tracking SystemRuby master - Bug #12050: Should feature processing really accept any substring of the feature name?https://bugs.ruby-lang.org/issues/12050?journal_id=568962016-02-05T03:22:29Znobu (Nobuyoshi Nakada)nobu@ruby-lang.org
<ul></ul><p>Intentional, and resolved in the defined order when it is ambiguous.<br>
I don't want to write <code>--enable=frozen-string-literal</code>, but <code>--enable=frozen</code> or shorter.</p> Ruby master - Bug #12050: Should feature processing really accept any substring of the feature name?https://bugs.ruby-lang.org/issues/12050?journal_id=569032016-02-05T14:52:03Zenebo (Thomas Enebo)tom.enebo@gmail.com
<ul></ul><p>Nobuyoshi Nakada wrote:</p>
<blockquote>
<p>Intentional, and resolved in the defined order when it is ambiguous.<br>
I don't want to write <code>--enable=frozen-string-literal</code>, but <code>--enable=frozen</code> or shorter.</p>
</blockquote>
<p>ok. Thanks for the clarification.</p> Ruby master - Bug #12050: Should feature processing really accept any substring of the feature name?https://bugs.ruby-lang.org/issues/12050?journal_id=569042016-02-05T14:56:49Zenebo (Thomas Enebo)tom.enebo@gmail.com
<ul></ul><p>Thomas Enebo wrote:</p>
<blockquote>
<p>Nobuyoshi Nakada wrote:</p>
<blockquote>
<p>Intentional, and resolved in the defined order when it is ambiguous.<br>
I don't want to write <code>--enable=frozen-string-literal</code>, but <code>--enable=frozen</code> or shorter.</p>
</blockquote>
<p>ok. Thanks for the clarification.</p>
</blockquote>
<p>Oh I should have read that closer...Resolves in the defined order if ambiguous? How would I know what that order is the defined order as an ordinary user?</p> Ruby master - Bug #12050: Should feature processing really accept any substring of the feature name?https://bugs.ruby-lang.org/issues/12050?journal_id=569112016-02-07T02:26:29Znobu (Nobuyoshi Nakada)nobu@ruby-lang.org
<ul></ul><p><code>ruby --help</code> shows:</p>
<pre><code>Features:
gems rubygems (default: enabled)
did_you_mean did_you_mean (default: enabled)
rubyopt RUBYOPT environment variable (default: enabled)
frozen-string-literal
freeze all string literals (default: disabled)
</code></pre> Ruby master - Bug #12050: Should feature processing really accept any substring of the feature name?https://bugs.ruby-lang.org/issues/12050?journal_id=569122016-02-07T04:45:57Zusa (Usaku NAKAMURA)usa@garbagecollect.jp
<ul></ul><p>I hope that it should be an <code>invalid option</code> error if it is ambiguous.<br>
And, when such case, showing the list of candidates (like did_you_mean) is better.</p>
<p>(Sorry, this comment may be a bikeshed.)</p> Ruby master - Bug #12050: Should feature processing really accept any substring of the feature name?https://bugs.ruby-lang.org/issues/12050?journal_id=569142016-02-07T09:28:39Znobu (Nobuyoshi Nakada)nobu@ruby-lang.org
<ul></ul><p>There is no ambiguous features now.<br>
And, as for similar option, <code>--dump</code> which has <code>parsetree</code> and <code>parsetree_with_comment</code>, I don't want it to err by <code>--dump=parse</code> but to dump just <code>parsetree</code>.<br>
Eliminating all ambiguities is not always convenient, I think.</p> Ruby master - Bug #12050: Should feature processing really accept any substring of the feature name?https://bugs.ruby-lang.org/issues/12050?journal_id=569152016-02-07T09:44:47Zusa (Usaku NAKAMURA)usa@garbagecollect.jp
<ul></ul><p>Nobuyoshi Nakada wrote:</p>
<blockquote>
<p>Eliminating all ambiguities is not always convenient, I think.</p>
</blockquote>
<p>The convenience is derived from your knowledge about the implementation.<br>
For others who are not familiar with the implementation, the behavior is unpredictable.<br>
The unpredictability may cause undesirable troubles.</p>
<p>Note that I don't talking about <code>--dump</code> option because it's for debugging the interpreter,<br>
and the debugger should know well about the implementation :-)</p> Ruby master - Bug #12050: Should feature processing really accept any substring of the feature name?https://bugs.ruby-lang.org/issues/12050?journal_id=569212016-02-07T20:17:41Zenebo (Thomas Enebo)tom.enebo@gmail.com
<ul></ul><p>Usaku NAKAMURA wrote:</p>
<blockquote>
<p>Nobuyoshi Nakada wrote:</p>
<blockquote>
<p>Eliminating all ambiguities is not always convenient, I think.</p>
</blockquote>
<p>The convenience is derived from your knowledge about the implementation.<br>
For others who are not familiar with the implementation, the behavior is unpredictable.<br>
The unpredictability may cause undesirable troubles.</p>
<p>Note that I don't talking about <code>--dump</code> option because it's for debugging the interpreter,<br>
and the debugger should know well about the implementation :-)</p>
</blockquote>
<p>I agree with you. For impl-specific options it is arguable whether ambiguity is important, but once enable/disable ends up with a potential ambiguous short-hand someone will end up getting confused.</p>
<p>The first feature encountered eliminates this ambiguity but I think most people would not expect this heuristic and they would expect an error on ambiguous entry. Of course, that is just one opinion :) Also, perhaps there will never be enough enable/disable options where they are ambiguous features.</p> Ruby master - Bug #12050: Should feature processing really accept any substring of the feature name?https://bugs.ruby-lang.org/issues/12050?journal_id=569262016-02-08T01:30:15Znobu (Nobuyoshi Nakada)nobu@ruby-lang.org
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Closed</i></li></ul><p>Applied in changeset r53772.</p>
<hr>
<p>ruby.c: err ambiguous feature name [ci skip]</p>
<ul>
<li>ruby.c (feature_option): raise a runtime error if ambiguous<br>
feature name is given, in the future. [Bug <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: Should feature processing really accept any substring of the feature name? (Closed)" href="https://bugs.ruby-lang.org/issues/12050">#12050</a>]</li>
</ul>