[ruby-core:73700] [Ruby trunk Bug#12050] Should feature processing really accept any substring of the feature name?

[ruby-core:73700] [Ruby trunk Bug#12050] Should feature processing really accept any substring of the feature name?

[tom.enebo]

Issue #12050 has been reported by Thomas Enebo.

----------------------------------------
Bug #12050: Should feature processing really accept any substring of the feature name?
https://bugs.ruby-lang.org/issues/12050

* Author: Thomas Enebo
* Status: Open
* Priority: Normal
* Assignee: 
* ruby -v: 
* Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN, 2.3: UNKNOWN
----------------------------------------
ruby --disable-gems -e 1
ruby --disable-gem -e 1
ruby --disable-ge -e 1
ruby --disable-g -e 1

I found this because in test_syntax.rb someone used --disable-gem and JRuby is currently doing matches on the full feature name and erroring otherwise.  If this is intentional it means no two features should ever start with the same letter...



-- 
https://bugs.ruby-lang.org/

[ruby-core:73703] [Ruby trunk Bug#12050] Should feature processing really accept any substring of the feature name?

[nobu]

Issue #12050 has been updated by Nobuyoshi Nakada.


Intentional, and resolved in the defined order when it is ambiguous.
I don't want to write `--enable=frozen-string-literal`, but `--enable=frozen` or shorter.

----------------------------------------
Bug #12050: Should feature processing really accept any substring of the feature name?
https://bugs.ruby-lang.org/issues/12050#change-56896

* Author: Thomas Enebo
* Status: Open
* Priority: Normal
* Assignee: 
* ruby -v: 
* Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN, 2.3: UNKNOWN
----------------------------------------
ruby --disable-gems -e 1
ruby --disable-gem -e 1
ruby --disable-ge -e 1
ruby --disable-g -e 1

I found this because in test_syntax.rb someone used --disable-gem and JRuby is currently doing matches on the full feature name and erroring otherwise.  If this is intentional it means no two features should ever start with the same letter...



-- 
https://bugs.ruby-lang.org/

[ruby-core:73714] [Ruby trunk Bug#12050] Should feature processing really accept any substring of the feature name?

[tom.enebo]

Issue #12050 has been updated by Thomas Enebo.


Nobuyoshi Nakada wrote:
> Intentional, and resolved in the defined order when it is ambiguous.
> I don't want to write `--enable=frozen-string-literal`, but `--enable=frozen` or shorter.

ok.  Thanks for the clarification.

----------------------------------------
Bug #12050: Should feature processing really accept any substring of the feature name?
https://bugs.ruby-lang.org/issues/12050#change-56903

* Author: Thomas Enebo
* Status: Open
* Priority: Normal
* Assignee: 
* ruby -v: 
* Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN, 2.3: UNKNOWN
----------------------------------------
ruby --disable-gems -e 1
ruby --disable-gem -e 1
ruby --disable-ge -e 1
ruby --disable-g -e 1

I found this because in test_syntax.rb someone used --disable-gem and JRuby is currently doing matches on the full feature name and erroring otherwise.  If this is intentional it means no two features should ever start with the same letter...



-- 
https://bugs.ruby-lang.org/

[ruby-core:73715] [Ruby trunk Bug#12050] Should feature processing really accept any substring of the feature name?

[tom.enebo]

Issue #12050 has been updated by Thomas Enebo.


Thomas Enebo wrote:
> Nobuyoshi Nakada wrote:
> > Intentional, and resolved in the defined order when it is ambiguous.
> > I don't want to write `--enable=frozen-string-literal`, but `--enable=frozen` or shorter.
> 
> ok.  Thanks for the clarification.

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?

----------------------------------------
Bug #12050: Should feature processing really accept any substring of the feature name?
https://bugs.ruby-lang.org/issues/12050#change-56904

* Author: Thomas Enebo
* Status: Open
* Priority: Normal
* Assignee: 
* ruby -v: 
* Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN, 2.3: UNKNOWN
----------------------------------------
ruby --disable-gems -e 1
ruby --disable-gem -e 1
ruby --disable-ge -e 1
ruby --disable-g -e 1

I found this because in test_syntax.rb someone used --disable-gem and JRuby is currently doing matches on the full feature name and erroring otherwise.  If this is intentional it means no two features should ever start with the same letter...



-- 
https://bugs.ruby-lang.org/

[ruby-core:73725] [Ruby trunk Bug#12050] Should feature processing really accept any substring of the feature name?

[nobu]

Issue #12050 has been updated by Nobuyoshi Nakada.


`ruby --help` shows:

```
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)
```

----------------------------------------
Bug #12050: Should feature processing really accept any substring of the feature name?
https://bugs.ruby-lang.org/issues/12050#change-56911

* Author: Thomas Enebo
* Status: Open
* Priority: Normal
* Assignee: 
* ruby -v: 
* Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN, 2.3: UNKNOWN
----------------------------------------
ruby --disable-gems -e 1
ruby --disable-gem -e 1
ruby --disable-ge -e 1
ruby --disable-g -e 1

I found this because in test_syntax.rb someone used --disable-gem and JRuby is currently doing matches on the full feature name and erroring otherwise.  If this is intentional it means no two features should ever start with the same letter...



-- 
https://bugs.ruby-lang.org/

[ruby-core:73726] [Ruby trunk Bug#12050] Should feature processing really accept any substring of the feature name?

[usa]

Issue #12050 has been updated by Usaku NAKAMURA.


I hope that it should be an `invalid option` error if it is ambiguous.
And, when such case, showing the list of candidates (like did_you_mean) is better.

(Sorry, this comment may be a bikeshed.)

----------------------------------------
Bug #12050: Should feature processing really accept any substring of the feature name?
https://bugs.ruby-lang.org/issues/12050#change-56912

* Author: Thomas Enebo
* Status: Open
* Priority: Normal
* Assignee: 
* ruby -v: 
* Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN, 2.3: UNKNOWN
----------------------------------------
ruby --disable-gems -e 1
ruby --disable-gem -e 1
ruby --disable-ge -e 1
ruby --disable-g -e 1

I found this because in test_syntax.rb someone used --disable-gem and JRuby is currently doing matches on the full feature name and erroring otherwise.  If this is intentional it means no two features should ever start with the same letter...



-- 
https://bugs.ruby-lang.org/

[ruby-core:73728] [Ruby trunk Bug#12050] Should feature processing really accept any substring of the feature name?

[nobu]

Issue #12050 has been updated by Nobuyoshi Nakada.


There is no ambiguous features now.
And, as for similar option, `--dump` which has `parsetree` and `parsetree_with_comment`, I don't want it to err by `--dump=parse` but to dump just `parsetree`.
Eliminating all ambiguities is not always convenient, I think.

----------------------------------------
Bug #12050: Should feature processing really accept any substring of the feature name?
https://bugs.ruby-lang.org/issues/12050#change-56914

* Author: Thomas Enebo
* Status: Open
* Priority: Normal
* Assignee: 
* ruby -v: 
* Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN, 2.3: UNKNOWN
----------------------------------------
ruby --disable-gems -e 1
ruby --disable-gem -e 1
ruby --disable-ge -e 1
ruby --disable-g -e 1

I found this because in test_syntax.rb someone used --disable-gem and JRuby is currently doing matches on the full feature name and erroring otherwise.  If this is intentional it means no two features should ever start with the same letter...



-- 
https://bugs.ruby-lang.org/

[ruby-core:73729] [Ruby trunk Bug#12050] Should feature processing really accept any substring of the feature name?

[usa]

Issue #12050 has been updated by Usaku NAKAMURA.


Nobuyoshi Nakada wrote:
> Eliminating all ambiguities is not always convenient, I think.

The convenience is derived from your knowledge about the implementation.
For others who are not familiar with the implementation, the behavior is unpredictable.
The unpredictability may cause undesirable troubles.

Note that I don't talking about `--dump` option because it's for debugging the interpreter,
and the debugger should know well about the implementation :-)

----------------------------------------
Bug #12050: Should feature processing really accept any substring of the feature name?
https://bugs.ruby-lang.org/issues/12050#change-56915

* Author: Thomas Enebo
* Status: Open
* Priority: Normal
* Assignee: 
* ruby -v: 
* Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN, 2.3: UNKNOWN
----------------------------------------
ruby --disable-gems -e 1
ruby --disable-gem -e 1
ruby --disable-ge -e 1
ruby --disable-g -e 1

I found this because in test_syntax.rb someone used --disable-gem and JRuby is currently doing matches on the full feature name and erroring otherwise.  If this is intentional it means no two features should ever start with the same letter...



-- 
https://bugs.ruby-lang.org/

[ruby-core:73734] [Ruby trunk Bug#12050] Should feature processing really accept any substring of the feature name?

[tom.enebo]

Issue #12050 has been updated by Thomas Enebo.


Usaku NAKAMURA wrote:
> Nobuyoshi Nakada wrote:
> > Eliminating all ambiguities is not always convenient, I think.
> 
> The convenience is derived from your knowledge about the implementation.
> For others who are not familiar with the implementation, the behavior is unpredictable.
> The unpredictability may cause undesirable troubles.
> 
> Note that I don't talking about `--dump` option because it's for debugging the interpreter,
> and the debugger should know well about the implementation :-)

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.

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.



----------------------------------------
Bug #12050: Should feature processing really accept any substring of the feature name?
https://bugs.ruby-lang.org/issues/12050#change-56921

* Author: Thomas Enebo
* Status: Open
* Priority: Normal
* Assignee: 
* ruby -v: 
* Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN, 2.3: UNKNOWN
----------------------------------------
ruby --disable-gems -e 1
ruby --disable-gem -e 1
ruby --disable-ge -e 1
ruby --disable-g -e 1

I found this because in test_syntax.rb someone used --disable-gem and JRuby is currently doing matches on the full feature name and erroring otherwise.  If this is intentional it means no two features should ever start with the same letter...



-- 
https://bugs.ruby-lang.org/