Proposal: Boolean.parseBoolean

Andrea Giammarchi andrea.giammarchi at gmail.com
Mon Mar 20 21:32:08 UTC 2017


I still think `Boolean.parse` makes sense only if gives us something more
than `JSON.parse` like `/^true|yes|y|1$/i.test(value)` would do.

Otherwise I personally don't see any real-world use case for it, specially
*not* those from bash or env variables.

On Mon, Mar 20, 2017 at 8:53 PM, Dmitry Soshnikov <
dmitry.soshnikov at gmail.com> wrote:

> On Mon, Mar 20, 2017 at 12:12 PM, Andrea Giammarchi <
> andrea.giammarchi at gmail.com> wrote:
>
>> As mentioned in the gist, and FWIW, -1 here.
>>
>> `/^true$/i.test(str)` works since ever for the specified use case
>>
>> `Boolean.parseBoolean(1)` that returns `false` is a footgun.
>>
>> Either we talk about a better definition of truthy-like values, or having
>> a public spec about just string type and `true` as value looks like the
>> solution for 1% of use cases that's also already covered by `JSON.parse`
>>
>>>
>>>
> Still, semantics matter :) With a `JSON.parse` you may parse any JSON
> value, and then will have to do extra checks. RegExp test is also less
> semantic. Initially in the thread I considered truthy/falsey values, but
> then reduced to strings only, and took Java's implementation, but this can
> be discussed. The need for a semantic method from `Boolean` still exists,
> instead of using ad-hoc technics like JSON or regexp, which are just
> implementation details for the semantic method.
>
> Dmitry
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170320/21fca64e/attachment.html>


More information about the es-discuss mailing list