Proposal: Boolean.parseBoolean

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Boolean.parseBoolean

Michael J. Ryan
I would add case insensitive "t", "y", "yes", 1, -1 as well


--
Michael J. Ryan - [hidden email] - http://tracker1.info

Please excuse grammar errors and typos, as this message was sent from my phone.

On Mar 20, 2017 11:54 AM, "Dmitry Soshnikov" <[hidden email]> wrote:
On Thu, Mar 16, 2017 at 1:55 PM, Dmitry Soshnikov <[hidden email]> wrote:
Similar to `Number.parseInt`, the `Boolean.parseBooelan` might be useful for "boolean strings" retrieved from some string-based storages, which do not support other types at serialization.

```
Boolean.parseBoolean('true'); // true
Boolean.parseBoolean('false'); // false
```



I made it plain simple (anything which is not case-insensitive `"true"` is `false`), and copy-pasted from Java.

Dmitry 

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Boolean.parseBoolean

Michael J. Ryan
My suggestion for a polyfill.

if (!Boolean.parse) {
  Boolean.parse = function(input) {
    // return false if it is already falsy
    if (!input) return false;

    var expr = String(input);

    // return false if it's reasonably too long of a string
    if (expr.length > 10) return false;

    // test trimmed input against truthy values
    return (/^(-?1|y|t|yes|true)$/).test(expr.trim().toLowerCase());
  }
}

-1/1 are common database boolean/bit fields
y/yes also common inputs for truthiness
t/true also common for truthiness

These account for pretty much every case of truthy stored values I've seen in the wild.

--- Dmitry, sorry, meant to reply-all the first time, also refactored the polyfill slightly to better account for potentially too long an input value.


--
Michael J. Ryan - http://tracker1.info

On Mon, Mar 20, 2017 at 4:41 PM, Michael J. Ryan <[hidden email]> wrote:
I would add case insensitive "t", "y", "yes", 1, -1 as well


--
Michael J. Ryan - [hidden email] - http://tracker1.info

Please excuse grammar errors and typos, as this message was sent from my phone.

On Mar 20, 2017 11:54 AM, "Dmitry Soshnikov" <[hidden email]> wrote:
On Thu, Mar 16, 2017 at 1:55 PM, Dmitry Soshnikov <[hidden email]> wrote:
Similar to `Number.parseInt`, the `Boolean.parseBooelan` might be useful for "boolean strings" retrieved from some string-based storages, which do not support other types at serialization.

```
Boolean.parseBoolean('true'); // true
Boolean.parseBoolean('false'); // false
```



I made it plain simple (anything which is not case-insensitive `"true"` is `false`), and copy-pasted from Java.

Dmitry 

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Boolean.parseBoolean

Dmitry Soshnikov
On Mon, Mar 20, 2017 at 4:59 PM, Michael J. Ryan <[hidden email]> wrote:
My suggestion for a polyfill.

if (!Boolean.parse) {
  Boolean.parse = function(input) {
    // return false if it is already falsy
    if (!input) return false;

    var expr = String(input);

    // return false if it's reasonably too long of a string
    if (expr.length > 10) return false;

    // test trimmed input against truthy values
    return (/^(-?1|y|t|yes|true)$/).test(expr.trim().toLowerCase());
  }
}

-1/1 are common database boolean/bit fields
y/yes also common inputs for truthiness
t/true also common for truthiness

Yeah, these might be good in general, although I'd like to reduce the proposal to minimum vital version, and JS related. The problem we are trying to solve is to parse `"false"` as `false`. It's not possible with `Boolean('false')` today. And all the JSON.parse, and regexp manipulations are too low-lever implementation details; users want good semantic library! :)

So:

```
Boolean.parse('true'); // true
Boolean.parse('false'); // false
```

That's all we need for now, and already will be much better semantic alternative too all existing "non-semantic building material".

Dmitry

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Boolean.parseBoolean

Michael J. Ryan
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?


--
Michael J. Ryan - http://tracker1.info

On Mon, Mar 20, 2017 at 10:47 PM, Dmitry Soshnikov <[hidden email]> wrote:
On Mon, Mar 20, 2017 at 4:59 PM, Michael J. Ryan <[hidden email]> wrote:
My suggestion for a polyfill.

if (!Boolean.parse) {
  Boolean.parse = function(input) {
    // return false if it is already falsy
    if (!input) return false;

    var expr = String(input);

    // return false if it's reasonably too long of a string
    if (expr.length > 10) return false;

    // test trimmed input against truthy values
    return (/^(-?1|y|t|yes|true)$/).test(expr.trim().toLowerCase());
  }
}

-1/1 are common database boolean/bit fields
y/yes also common inputs for truthiness
t/true also common for truthiness

Yeah, these might be good in general, although I'd like to reduce the proposal to minimum vital version, and JS related. The problem we are trying to solve is to parse `"false"` as `false`. It's not possible with `Boolean('false')` today. And all the JSON.parse, and regexp manipulations are too low-lever implementation details; users want good semantic library! :)

So:

```
Boolean.parse('true'); // true
Boolean.parse('false'); // false
```

That's all we need for now, and already will be much better semantic alternative too all existing "non-semantic building material".

Dmitry


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Boolean.parseBoolean

Dmitry Soshnikov
On Tue, Mar 21, 2017 at 11:49 AM, Michael J. Ryan <[hidden email]> wrote:
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.

Dmitry 

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Boolean.parseBoolean

Jordan Harband
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 <[hidden email]> wrote:
On Tue, Mar 21, 2017 at 11:49 AM, Michael J. Ryan <[hidden email]> wrote:
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.

Dmitry 

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
12