How about a "named true" and a "named true property"

Andy Earnshaw andyearnshaw at gmail.com
Thu May 26 09:59:29 UTC 2016


This is more a problem to be solved in API design and if you see such a
method being introduced to libraries or specifications, you should raise
your concerns with the author(s).  Fortunately, Ecma-262 seems to avoid
this pitfall by accepting objects-as-dictionaries, and most newer web APIs
seem to be trending towards the same thing.  Even jQuery has made an effort
to do the same[1].

You don't even need to use variables to avoid the boolean trap in
third-party APIs, you can simply use strings:

$.clone(sourceObject, !!'deep'); // true
$.clone(sourceObject, !'deep'); // false

This is more akin to the your `:removeNode` example and is something that a
minifier or engine may optimise for you.

[1]: https://bugs.jquery.com/ticket/13103

On Thu, 26 May 2016 at 10:35 Oriol Bugzilla <oriol-bugzilla at hotmail.com>
wrote:

> As Isiah Meadows said, you can just use variables.
>
> ```
> var removeNode = true;
> control.dispose(removeNode);
> ```
>
> ```
> var silent = true,
>       disableValidation = true,
>       destroyOldValue = false;
> model.set('foo', newValue, {silent, disableValidation, destroyOldValue});
> ```
>
> ------------------------------
> From: otakustay at gmail.com
> Date: Thu, 26 May 2016 09:02:21 +0000
> Subject: How about a "named true" and a "named true property"
> To: es-discuss at mozilla.org
>
>
> I don't really know how to name this feature, but I find it quite
> neccessary
>
> In JavaScript land there are many functions with parameters of type
> boolean, and invocations to these functions do not have high readability,
> for example jQuery have a `clone` method with a parameter deep of type
> boolean, but when read a code like:
>
> ```
> $.clone(sourceObject, true);
> ```
>
> it's hard to understand what is that `true` stands for, a more unfamiliar
> API could make this more uncomfortable:
>
> ```
> control.dispose(true); // does it mean "to remove DOM node or anything
> else?"
> ```
>
> In practice we can write some comment after a boolean parameter to explain
> what it is:
>
> ```
> control.dispose(true /* removeNode */);
> ```
>
> but it's a lot of work.
>
> In this case I think we may introduce a handy syntax called "named true"
> which only transforms to the keyword `true` but have a custom name:
>
> ```
> control.dispost(:removeNode);
> ```
>
> Here a leading colon hints it is a "named true" so in parsing stage
> `:removeNode` simply becomes `true`, and we can have a false value with
> simply `!:removeNode`, it doesn't hit performance but notably increase
> readability
>
> Boolean parameters is not good practice but I believe it is
> not eliminated nowadays and will never be eliminated, so a more friendly
> syntax could save a lot of time
>
> ---
>
> Furthermore, there are also many functions accepting an `options`
> parameter including some "flag properties", flag properties are simple
> properties with a boolean value, a good example is the {silent: true} flag
> in many event related APIs.
>
> Constructing an `options` object containing flag properties are not easy,
> we may repeat `: true` and `: false` many times, so with previously "named
> true", I think a "named true property" could help to save time:
>
> ```
> model.set('foo', newValue, {:silent, :disableValidation,
> !:destroyOldValue})
> ```
>
> Here `:silent` is simply parsed to `silent: true` and `!:destroyOldValue`
> is for `destroyOldValue: false`, it can save a large amount of code
>
> All syntax here are just examples, not any propose to grammar
>
> _______________________________________________ es-discuss mailing list
> es-discuss at mozilla.org https://mail.mozilla.org/listinfo/es-discuss
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160526/7b344f9f/attachment-0001.html>


More information about the es-discuss mailing list