what's wrong with .bind() ?
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
