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
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
