This has been previously discussed on nodejs -
http://groups.google.com/group/nodejs/browse_thread/thread/220f9faac1b61798/8f3e85ec7e73f806?lnk=gst&q=nikhil+marathe
On Sat, Jun 9, 2012 at 3:44 AM, AJ ONeal <coola...@gmail.com> wrote:
> Interesting. So have you found bind() to be more or less efficient than
> .call() and or .apply()?
>
> AJ ONeal
>
>
> On Fri, Jun 8, 2012 at 3:48 PM, Jimb Esser <wastel...@gmail.com> wrote:
>>
>> Technically, at least in V8, .bind is a lot lighter weight than an
>> anonymous function. There are a large number of micro-benchmarks to look at
>> on jsperf.com, but for an actual anecdote, at one point we accidentally
>> required in a module which overrode Function.prototype.bind with something
>> that created an anonymous function (some browser-support code for pre-.bind
>> browsers), and our performance tanked, garbage collection times increased
>> significantly.
>>
>>
>> On Fri, Jun 8, 2012 at 2:25 PM, AJ ONeal <coola...@gmail.com> wrote:
>>>
>>> If I'm not mistaken, bind() has the same technical drawbacks as using an
>>> anonymous function (higher memory usage, more garbage collection, and slower
>>> says Tim), but it does solve the maintainability / prettiness issue.
>>>
>>> I just want to point out that Raspberry Pi is now shipping.
>>> NodeJS is a very attractive option for development.
>>>
>>> My own experience with my ARM-based media server has lead me to be a
>>> believer in prototypes and leaner code. I can't say that one little anony
>>> here and there is going to blow up an application, but I know for a fact
>>> that there are significant performance gains when they are avoided.
>>>
>>> I know it doesn't seem like a big deal now. But one day you may change
>>> your mind.
>>>
>>> AJ ONeal
>>>
>>> On Fri, Jun 8, 2012 at 2:22 PM, George Stagas <gsta...@gmail.com> wrote:
>>>>
>>>> No need to change the API, we have .bind() - use the language
>>>> features, don't reinvent them.
>>>>
>>>> 2012/6/8 Tim Caswell <t...@creationix.com>:
>>>> >
>>>> >
>>>> > On Fri, Jun 8, 2012 at 2:10 PM, tjholowaychuk <tjholoway...@gmail.com>
>>>> > 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 <coola...@gmail.com> 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 <t...@creationix.com>
>>>> >> > 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 <coola...@gmail.com>
>>>> >> > > 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
>>>> >> > >> <t...@creationix.com>
>>>> >> > >> 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 <coola...@gmail.com>
>>>> >> > >>> wrote:
>>>> >> >
>>>> >> > >>>> Yes, That's what I am suggesting.
>>>> >> >
>>>> >> > >>>> AJ ONeal
>>>> >> >
>>>> >> > >>>> On Fri, Jun 8, 2012 at 12:17 PM, Tim Caswell
>>>> >> > >>>> <t...@creationix.com>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 <coola...@gmail.com>
>>>> >> > >>>>> 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
>>>> >
>>>> >
>>>
>>>
>>
>
