No need to change the API, we have .bind() - use the language features, don't reinvent them.
2012/6/8 Tim Caswell <[email protected]>: > > > On Fri, Jun 8, 2012 at 2:10 PM, tjholowaychuk <[email protected]> > wrote: >> >> what's wrong with .bind() ? >> > > Mainly the overhead. Bind creates a new function every time it's called, > and calling the bound function is a bit slower, especially in V8. (Insert > statement about performance only mattering if it's significant...) > > I usually will bind all my methods from the prototype that will be used as > callbacks to the instance itself inside the constructor. This gives me a > ton more "own" properties, but otherwise is fairly elegant. > >> >> On Jun 8, 11:52 am, AJ ONeal <[email protected]> wrote: >> > emitter.on('data', myModule.dataHandler, myModule); >> > >> > Even if myModule were to subclass EventEmitter, wouldn't I still need to >> > pass in the `myModule` instance so that I get the correct `this`? I >> > don't >> > think I understood what you meant by that. >> > >> > And then these cases as well: >> > >> > fs.readFile(file, encoding, myModule.fileHandler, myModule); >> > >> > process.nextTick(myModule.tickHandler, myModule); >> > >> > The list goes on. Obviously not a small project. Not difficult either, >> > just >> > tedious. >> > >> > AJ ONeal >> > >> > >> > >> > >> > >> > >> > >> > On Fri, Jun 8, 2012 at 12:42 PM, Tim Caswell <[email protected]> >> > wrote: >> > > Actually event emitters already call in the scope of the emitter, so >> > > there >> > > is no need for a specific "this" value there. Just subclass >> > > EventEmitter >> > > and use normal methods. >> > >> > > On Fri, Jun 8, 2012 at 1:34 PM, AJ ONeal <[email protected]> wrote: >> > >> > >> If you're going to use `this` then you must have a callback. It would >> > >> make no sense to have a `this` and nothing to apply it to. >> > >> > >> You think EventEmitters would feel the overhead of the if? >> > >> > >> // context is Array, Object, or Function. >> > >> // Numbers, Strings, and Booleans need not `apply` (very punny) >> > >> if (context) { >> > >> fn.call(context, a, b, c); >> > >> } else { >> > >> fn(a, b, c); >> > >> } >> > >> > >> As far as the guesswork, well, I hear you on that. I've already done >> > >> my >> > >> ranting at UtahJS Conf. Put this as one more in the bucket of reasons >> > >> that >> > >> callbacks-last was not a well-thought out idea.... >> > >> > >> AJ ONeal >> > >> > >> On Fri, Jun 8, 2012 at 12:27 PM, Tim Caswell <[email protected]> >> > >> wrote: >> > >> > >>> I think it's a useful addition, but it does cause a little overhead >> > >>> (though it's probably not noticeable compared to the actual work the >> > >>> async >> > >>> function is doing). EventEmitters might feel the pain since they >> > >>> are sync. >> > >>> I do worry that it makes things harder for our argument guessing >> > >>> code that >> > >>> assumes the last arg is a callback. Now there will be an optional >> > >>> argument >> > >>> after the callback that can be anything (including another function) >> > >> > >>> On Fri, Jun 8, 2012 at 1:18 PM, AJ ONeal <[email protected]> wrote: >> > >> > >>>> Yes, That's what I am suggesting. >> > >> > >>>> AJ ONeal >> > >> > >>>> On Fri, Jun 8, 2012 at 12:17 PM, Tim Caswell >> > >>>> <[email protected]>wrote: >> > >> > >>>>> So this proposal is to modify the API of all async functions to >> > >>>>> have >> > >>>>> an extra thisp argument after the callback argument (like done in >> > >>>>> Array.prototype.forEach)? >> > >> > >>>>> On Fri, Jun 8, 2012 at 1:06 PM, AJ ONeal <[email protected]> >> > >>>>> wrote: >> > >> > >>>>>> I would like to propose that an additional parameter, `context` >> > >>>>>> be >> > >>>>>> added to core node modules that accept callbacks to give >> > >>>>>> this-ness to the >> > >>>>>> callback. >> > >> > >>>>>> The reason being is that I'm trying to eliminate anonymous >> > >>>>>> callbacks >> > >>>>>> from my code and have generally cleaner, more readable code (as >> > >>>>>> well as >> > >>>>>> lower memory usage and less garbage collection). >> > >> > >>>>>> I don't know if this has been discussed before, but I'd like to >> > >>>>>> put >> > >>>>>> it on the table. >> > >> > >>>>>> AJ ONeal > >
