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