'this' context overrides in JavaScript functions

[Sean Copenhaver]

I brought up the use of 'this' in callback APIs at lunch today. If it's good or bad, confusing, or less safe. Node.js seems to never use 'this' and everything is explicitly passed into the function (pretty consistently as well), but if you take a look at jQuery generally they are always setting 'this'.

I'm not sure how I feel about it. Explicitly passed in parameters are certainly safer and less confusing, but being able to set the context of a function is an interesting flexibility that JavaScript has. Perhaps with 'use strict' pragma support it'll be fine since (I believe) 'this' won't be able to be the global object and will throw an error. Anyone have thoughts on 'this'?

How would you design a JavaScript API?

--
“The limits of language are the limits of one's world. “ - Ludwig von Wittgenstein

"Water is fluid, soft and yielding. But water will wear away rock, which is rigid and cannot yield. As a rule, whatever is fluid, soft and yielding will overcome whatever is rigid and hard. This is another paradox: what is soft is strong." - Lao-Tzu

[Bryan Matthews]

Ironically I recently ran into a bug with a coworker that was due to "this" object confusion.  In his case he was using a callback to a function that specified this, then refactored to use a different function that didn't specify this and missed changing some of the code along the way (happened to be short-circuited).

<tangent>

I think this is a good reason to by default use a to-javascript language like coffeescript, or anything else for that matter.  (It seems that never a day goes by that I don't think of a reason).  Since it is compiled you can do basic syntax and logic checking and fail to compile in many cases.  With better support for modules this can only get better and better.  I suspect that we will go even farther in coming years in terms of some functionality that people are used to in their IDEs (intellisense, refactor helpers, real-time syntax checking, etc.) for javascript and to-javascript languages.  Hopefully the era of "change a bunch of stuff and see if it breaks in the browser" is coming to an end.  Some might say that we should be using tests (and I agree) to validate our software, but the people who aren't going to do it simply aren't going to do it no matter how good or bad the tooling support is.  Just might make things easier on some of the rest of us.  Also, I think it is a win for the community that a project like rails moves to support coffeescript by default, and hopefully we'll see similar moves by others.

p.s.  I don't hate JavaScript

</tangent>

I think this works for jQuery, since everything is the DOM, and therefore everything is an element, so there should pretty much always be an element to use for "this".  In other words, their API is pretty homogeneous.

Still, I think I prefer the explicit route in most cases.  I like the idea of coffeescript's fat arrow syntax to enable keeping this in the scope of the current object inside of "instance methods", and avoiding abusing it in other cases where it isn't necessary (as in jQuery).

--
You received this message because you are subscribed to the Google
Groups "ColaCodeDojo" group.
To post to this group, send email to colaco...@googlegroups.com
To unsubscribe from this group, send email to
colacodedojo...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/colacodedojo?hl=en

[jed schneider]

also, a really good justification for doing javascript testing (very simple to catch callback changes and other refactoring woes). as a side note coffeescript and underscore.js has made me love javascript again.

-- 
jed schneider
Sent with Sparrow