Although the general recommendation is not to extend prototypes, if you *do* extend them, it's best to do so by calling Object.defineProperty() with enumerable set to false, so they don't show up in iterators (just like all other functions on the built-in prototypes). Otherwise, using your code will break any other modules anywhere that iterate over members with a for..in iterator. We've ran into a few cases where including a new 3rd party module incorrectly extended a prototype and broke some other 3rd party module which was iterating over object properties (without using a .hasOwnProperty guard).
Admittedly, extending the Function prototype is not as risky as extending the Object prototype, but it's still best to be safe if you want people to use your module. On Wednesday, March 20, 2013 2:08:28 PM UTC-7, Ken wrote: > > Since the end game for all my recent thought experiments seems to be more > NPM clutter, I made this into a module: callback-wrappers > > https://npmjs.org/package/callback-wrappers > https://github.com/femto113/node-callback-wrappers > > Per suggestions from the group, by default it just exports some functions > that take callbacks as arguments, but it also gives a method to punch them > all into Function.prototype if you like that style better. > > Thanks, > --Ken > > On Tuesday, March 19, 2013 4:44:05 PM UTC-7, Ken wrote: >> >> I've been writing a bunch of shell-script-like node scripts lately. >> These mostly call a series of async functions that take the usual function >> (error, data) { ... } callback, and generally they handle any error >> along the way by logging it and exiting. Here's a naive example using >> aws-sdk to make a couple EC2 API calls in serial >> >> var AWS = require("aws-sdk"); >> >> var ec2 = new AWS.EC2.Client(); >> >> ec2.runInstances({ ... }, function (error, runInstancesResponse) { >> if (error) { >> console.log(error); >> process.exit(1); >> } else { >> // ... get the instanceIds from response as input to createTags >> ec2.createTags({ ... }, function (error, createTagsResponse) { >> if (error) { >> console.log(error); >> process.exit(2); >> } else { >> // ... do further processing ... >> } >> }); >> } >> }); >> >> As you can see a lot of the total lines are just totally boilerplate if >> (error) barf. Since we've got a functional language here, pretty easy >> to encapsulate that, e.g. with this >> >> Function.prototype.xie = Function.prototype.exitIfError = function >> (exitCode) { >> var f = this; >> return function (error, data) { >> if (error) { >> console.log(error); >> process.exit(exitCode || 1); >> } else { >> f.call(this, data); >> } >> }; >> } >> >> our code collapses to just >> >> ec2.runInstances({ ... }, function (runInstancesResponse) { >> // ... get the instanceIds from response as input to createTags >> ec2.createTags({ ... }, function (createTagsResponse) { >> // ... do further processing ... >> }.xie(2)); >> }.xie(1)); >> >> Which feels a lot more readable to me. Is there precedent for this >> technique? A name for it? Any well known modules that implement it? Any >> obvious horrible side effects? Clearly not applicable to sophisticated >> error handling, but for this basic "it all works or just give up" kind of >> thing it seems handy. Could add "abort if error", "throw if error", "emit >> if error" flavors as well. >> >> -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
