> displayMapAt(center, 14);
> });
To my eyes, that solution is just fine. I don't think I'll ever be swayed to believe that adding on layers of indirection to JavaScript code for the sake of "syntactic goodness" is rationally motivated by leading to more practical power for actually solving problems.
All software should be as complex as it needs to be to do the job, and no more so (where complex means the cognitive load necessary to understand it). Unfortunately 99% of programmers and 100% of programmers' managers don't understand this (both numbers are probably correct to the nearest integer, in my experience).
Sometimes brevity isn't the right solution.
js> var _
js> _ == undefined
true
Just doing "var _ = {}" should be sufficient.edit: however, this conflicts with Underscore.js (http://documentcloud.github.com/underscore/), but if you put an "if (typeof _ === "undefined")" around the assignment you should be ok
js> a = {}
[object Object]
js> b = {}
[object Object]
js> a == b
false
== only casts between certain primitive types, it doesn't do a deep comparison: js> x = null
null
js> y = undefined
js> x == y
true
js> x === y
false
Also undefined comparisons are still true with ===: js> var _
js> _ === undefined
true
But you're right, === should be the default choice, and only use == if you have a good reason. geolocator.getLatLng("Forest Park, St. Louis, MO", displayMapAt);
Is better than this? displayMapAt(geolocator.getLatLng("Forest Park, St. Louis, MO"));
That is, why is it more sensible for getLatLng to accept a callback function that will accept its result, when one can just pass its result to a function?Another way to do this sort of thing, that might feel more composable: have geolocator.getLatLng() return a 'promise' object that will be asynchronously resolved.