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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss