andrea.giammarchi at gmail.com
Mon Mar 20 19:12:36 UTC 2017
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`
On Mon, Mar 20, 2017 at 7:07 PM, James Treworgy <jamietre at gmail.com> wrote:
> I'd say there's no clear model for consistenty, e.g. JSON.parse. One could
> argue that the template is that anything which has only one way to parse is
> to use `parse`. Numbers have more than one way (`parseInt`, `parseFloat`)
> On Mon, Mar 20, 2017 at 3:04 PM, Dmitry Soshnikov <
> dmitry.soshnikov at gmail.com> wrote:
>> On Mon, Mar 20, 2017 at 11:57 AM, T.J. Crowder <
>> tj.crowder at farsightsoftware.com> wrote:
>>> Any reason for not just using `Boolean.parse`? (Rather than repeating
>>> `Boolean` in the function name?)
>> Just a copy-paste from Java, similarly was done with `parseInt` taken
>> from Java. But just `parse` probably would work too. For consistency and
>> predictability `parseBoolean` is probably better now.
>> es-discuss mailing list
>> es-discuss at mozilla.org
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss