ljharb at gmail.com
Wed Mar 22 00:39:44 UTC 2017
The good answer is that `Boolean(x)` is the same as `‼x` (which is a good
thing) - and the string "false" is truthy, since the only falsy string
value is the empty string.
On Tue, Mar 21, 2017 at 1:08 PM, Dmitry Soshnikov <
dmitry.soshnikov at gmail.com> wrote:
> On Tue, Mar 21, 2017 at 11:49 AM, Michael J. Ryan <tracker1 at gmail.com>
>> I slightly disagree... mainly in that as it stands, we have a fairly
>> loose type coercion system that allows almost anything to be coerced into a
>> boolean... in this case "parse" at least in my mind means that it should
>> cover the most common use cases. I understand that Boolean("false")
>> doesn't currently work this way, and why Date.parse doesn't give a date
>> instance is a bit beyond me.
>> With my suggested polyfill your use case would work as expected...
>> However, JS interacts with more than just serialized results from JS. It
>> interacts with input from multiple systems, sources, users and good/bad the
>> content of users. The type coercion as it exists for boolean is in order
>> to provide for simplistic validation... why an empty string coerces false,
>> for example. Much like we have defined "falsey" values in JS, I think that
>> Boolean.parse should have common truthy values/strings that can predictably
>> be converted as a true, where all else is false.
>> If all it does is:
>> input => String(input).toLowerCase() === 'true';
>> what is the point of extending Boolean?
> Yeah, all good points, but they open a door for more questions mentioned
> above (so many different formats, "yes", "1", "on", etc, and "why one, but
> not another?", and "why not i18n?").
> So to reduce this, having a good MVP would be good. Then, if there is a
> need, it can be extended by adding.
> The actual practical use-case I want to solve is:
> - Not to use "raw building material" (aka "syntactic garbage") to solve
> the issue. With this I mean using non-semantic techniques to achieve the
> goal, like RegExp testings, JSON.parsing, etc. This is also a building
> material: "String(input).toLowerCase() === 'true';", and users want nice
> semantic library.
> - To solve `Boolean('false')` issue. This is an actual use-case I had,
> when was asked why Boolean type coercion treats "false" as true, and there
> is no good answer other than -- "it's specified so". So to keep backward
> compats we need Boolean.parse(...) for this.
> So the only question it needs to address whether we accept truthy/false
> values, or only strings.
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss