I think we have lots of occasions to receive a
false value as a string input, and want to convert it to
false. Perhaps we can have a method
Kernel#Boolean in a similar spirit to
Kernel#Integer and its kins, which takes an optional keyword argument
exception (similar to https://bugs.ruby-lang.org/issues/12732) and
strict (defaulted to true).
Boolean("true") # => true Boolean("false") # => false Boolean("foo") # => ArgumentError Boolean("foo", exception: nil) # => nil Boolean("1") # => ArgumentError Boolean("1", strict: false) # => true Boolean("yes", strict: false) # => true Boolean("0", strict: false) # => false Boolean("no", strict: false) # => false Boolean("foo", strict: false, exception: nil) # => nil
Updated by matz (Yukihiro Matsumoto) about 2 years ago
- Status changed from Open to Feedback
The proposal is still vague, especially when
strict: false. The criteria are totally culture dependent.
"yes" may be true for English speaking people, but what about "はい" (Japanese) or "Ja" (German)? The list would go on.
Until the ambiguity resolved, I am against the proposal.
Updated by shevegen (Robert A. Heiler) about 2 years ago
I think we have lots of occasions to receive a true or false value as a string input, and
want to convert it to true or false.
I agree. :)
Not saying that I agree with the API, it feels a bit cumbersome; but I agree with the
By the way, I think the first two cases are the one that are the least ambiguous
since they only evaluate the two strings "true" and "false" into the respective
true and false representation:
Boolean("true") # => true
Boolean("false") # => false
(The name "Boolean" is a bit strange though... where does this reside then? In
Kernel? Why not to_bool or to_boolean? Though admittedly the latter also includes
the word "boolean", I guess the uppercased leading part confuses me a bit. I am
aware of Kernel#Integer() or whever it resides, but I think that in general it
may be better to not use too many upcased method names; in ruby we have a lot of
flexibility like .Foo() or class Foo; Foo - but anyway, this is a side comment,
as written above I agree with what Tsuyoshi Sawada stated :) )