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 <[email protected]> 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: [email protected] > Date: Thu, 26 May 2016 09:02:21 +0000 > Subject: How about a "named true" and a "named true property" > To: [email protected] > > > 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 > [email protected] https://mail.mozilla.org/listinfo/es-discuss > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
