FWIW, I just use `Object` most of the time as both no-op and identity (beside primitives, but I rarely have primitives on callback arguments where I need the no-op).
I agree with Mark arrow makes everything ever more explicit and allocation is an engine concern, something that could even not ever happen if it's smart enough to transform no-ops into no-ops and identities into identities. Just my 2 cents On Wed, Aug 10, 2016 at 3:25 PM, Eli Perelman <[email protected]> wrote: > I can understand the sentiment of wanting brevity and avoiding unnecessary > abstraction, but in some cases I think it comes at the cost of readability > or good practice. This is why variables exist at all: to store commonly > used values either for reuse or to cut down on unnecessary allocation. > > Sure, I could write code to ensure my numbers did go over a certain limit > with `Math.min(userInput, 9007199254740991)`, but readability and > abstraction give me something without having to keep this knowledge > internally and create my own allocation, e.g. `Math.min(userInput, > Math.MAX_SAFE_INTEGER`. > > Now obviously it would be trivial for me to declare these constants in > userland code like I already do, e.g. `const NOOP = () => {}`, but in > projects where it's needed in several files, I'll have to put that in a > module or re-declare everywhere. This is not a huge inconvenience but > something that could easily allocated for in the language. > > > The semantics of the named forms can be guessed rather well from the > names, but one cannot be sure without looking up or remembering their > definitions. > > This is true of anything; you know what you know, and are unsure of what > you are unsure of. Those that understand what a no-ops and identity > functions are will not need to look it up, and those that do not will look > it up until they know it. Just like my personal enemies `Array#shift` and > `Array#unshift`, I have to look those up every single time, and just > because I can't remember which is which or their individual case doesn't > mean they don't have value or that I resort to other tricks to avoid their > usage. All that to say, I don't think lack of knowledge is a valid argument > for these constants' non-inclusion. :) > > > Only pay these costs when the potential benefits are real. > > I think my allusion to potential benefits is avoidance of re-declaration > (DRY) and allocation. > > Just my thoughts. :) > > Eli Perelman > > > > On Wed, Aug 10, 2016 at 9:08 AM Mark S. Miller <[email protected]> wrote: > >> On Wed, Aug 10, 2016 at 2:10 AM, Isiah Meadows <[email protected]> >> wrote: >> >>> I'll note that it's longer than just typing them out manually (and close >>> if they're aliased): >>> >>> ```js >>> Function.IDENTITY >>> IDENTITY >>> x => x >>> >>> Function.NOOP >>> NOOP >>> () => {} >>> ``` >>> >>> Not sure if it adds anything. >>> >> >> Even aside from brevity, `x => x` and `() => {}` are more readable than >> `Function.IDENTITY` and `Function.NOOP` for a very simple reason. The >> semantics of the shorter forms are obvious and clear, give knowledge only >> of the core language. The semantics of the named forms can be guessed >> rather well from the names, but one cannot be sure without looking up or >> remembering their definitions. As we all know, abstraction has tremendous >> potential benefits. But it also has these costs -- the need to learn the >> meaning of new definitions. Only pay these costs when the potential >> benefits are real. >> >> Also, other things being equal, a briefer form is easier to read. In this >> case, other things are not equal but both considerations point in the same >> direction. >> >> >>> On Tue, Aug 9, 2016, 14:44 Eli Perelman <[email protected]> wrote: >>> >>>> I'm not sure if something like this has been proposed before, but I >>>> often find myself declaring constants for the identity function and the >>>> no-op function. I think it would be useful to have constants available on >>>> Function containing these values. For example `Function.IDENTITY` and >>>> `Function.NOOP`. Essentially these constants would map to: >>>> >>>> ```js >>>> Function.IDENTITY = (a) => a; >>>> Function.NOOP = () => null; // or: >>>> Function.NOOP = () => {}; >>>> ``` >>>> >>>> These could then be used in places where non-user-controlled APIs need >>>> default functions need to be executed, or as placeholders for default >>>> values that may be executed before a function has been supplied. For >>>> example: >>>> >>>> ```js >>>> // third-party API requires a callback or throws, but no functionality >>>> really needs to done: >>>> thirdParty.action(Function.NOOP); >>>> >>>> // Function needs a default which *may* execute prior to having a >>>> different one specified (contrived): >>>> const action = (handler = Function.IDENTITY, value = 10) => >>>> handler(value); >>>> ``` >>>> >>>> Thoughts? Seems like something simple with positive value. Thanks! >>>> >>>> Eli Perelman >>>> _______________________________________________ >>>> 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 >>> >>> >> >> >> -- >> Cheers, >> --MarkM >> > > _______________________________________________ > 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
