Crockford is an excellent writer. You should check out his book "Javascript: The Good Parts" if you liked that article, it's one of the best programming books I've read in a long time.
While it's a pretty good book, I found it repetitive and filled with what I would consider somewhat arbitrary "style" guidelines (don't use increment or decrement operators? fall-through case statements?).
Also, it only covers the language, since the DOM isn't a "good part". I would recommend "JavaScript: The Definitive Guide" (a.k.a. the rhino book, which the Rhino JS interpreter is named after...). I keep that one next to my desk at all times.
But in summary, "JavaScript: The Good Parts" is a good supplement to other materials (though most of what's contained in the book can be learned from his website and video lectures)
For some reason, nesting closures like that seems very reminiscent of how you'd implement objects in Scheme.
So I guess there's some truth to the rumour that Javascript is basically Scheme with C syntax. Either that, or I've drunk too much coffee this morning...
Just think about this, I know a fellow programmer (A C fan), that used to pun another one (his best friend A C++ guru) - so the former used to have this:
#define private public
#define protected public
This just shows how fragile the protection of member variables in C++ is (side effect of the pre-processor).
After all, good C++ books recommend hiding data through other means (pointer that points to structure not published anywhere else (like in a library))
Wow, that really is an incisive article! I've been hacking AS2 + 3 for the last 7 years after being a proper JS head for the previous 4, this makes me want to get back and hacksome JS for fun again!
It's sort of a matter of taste. I use this pattern in Lua of having public attributes visible in my objects, with private values stored as enclosing outer local variables. (They're referred to as "upvalues" in Lua. It's a handy bit of vocab.)
Public object attributes are iterable and otherwise manipulable by clients of the object. Upvalues are opaque to clients - you need the debugger to inspect the local stack frames. They're perfectly accessible to the closures acting as methods on your object though.
It really just comes down to your mental model of the object in question.
This constructor makes three private instance variables: param, secret, and that. They are attached to the object, but they are not accessible to the outside, nor are they accessible to the object's own public methods. They are accessible to private methods. Private methods are inner functions of the constructor.
Call me dim, but if you can define private members which can't even be accessed by public members and only in the constructor, how are they anything except local?
I might be doing needlessly geeky nitpicking here, but "private" has a standardized meaning in pretty much all OOP languages, and calling this private just seems silly.
Edit: Reading the whole thing, it seems the butchered public and not private. Making public something different all together, and having "privileged" being the actual, usual public-modifier.
You can stick public functions onto your object while you're in the constructor, that makes any variables local to the constructor available only via said public method, effectively capturing them in the closure created by the inner function. After the constructor dies, its environment is kept alive by any of those functions and it acts exactly like private instance variables in your other common OO languages.
Ah well. I'll rephrase myself and say any OOP language I have any significant knowledge about then ;)
But both C#, VB.Net and pretty much any OOP language I have touched has been like that. Granted I've seen different meanings for static and protected, but I've never seen this behaviour before.
When in doubt go to the source of the ideas, to see who got the labels wrong. C#, VB.Net, Java, and even C++ are nowhere near the source on OOP (and they are all in the same lineage...while JavaScript shares far more with Scheme and SmallTalk, and is thus on a quite different road).
One should be careful about thinking "different" means "wrong".
http://video.yahoo.com/watch/111593/1710507 (Part 1)
http://video.yahoo.com/watch/111594/1710553 (Part 2)
http://video.yahoo.com/watch/111595/1710607 (Part 3)
http://video.yahoo.com/watch/111596/1710658 (Part 4)
There are also a series on DOM, advanced stuff etc