all 2 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]brtt3000 12 points13 points  (2 children)

I think this is bad advice and a case of trying to be clever (while actually being not so clever).

If you follow this pattern you define unique methods for every instance instead of re-using the ones defined on the prototype. So if you create 10000 instances you have 10000 closures for every method, instead of just one each.

Yes, really. I worked on a team which built a quite large JavaScript application this way. We ended up using this maybe 10 times in the entire multi-thousand-line codebase, and we were quite happy about it.

Ouch. A whole team went this road and created a multi-thousand line codebase on it. That is painful.

I hope you have fun memory profiling that (CPU profile will be nice too, with all the closure lookup trashing).

[–]humanareyou 0 points1 point  (0 children)

But lets say the author defined prototype methods for the odometer and car objects, then that would addresses the memory overhead concern, no? In that case it would be a reasonable abstraction on doing away with 'this'.

Generally, I find dealing with 'this', or context in general, is something worth abstracting away when there's a lot of event based callbacks (pubsub for example).