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 < [email protected]> wrote: > On Mon, Mar 20, 2017 at 12:12 PM, Andrea Giammarchi < > [email protected]> 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 >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
