This is the page that made doing OOP in Javascript click for me. | Hacker News Reader

This is the page that made doing OOP in Javascript click for me.

crockford.com

74 pointsedw51921 comments

Open articleView on HN

The video lectures on yahoo from Doug are even better. He goes through all of these details in them.

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

If anyone wants to download the four part series, here it is concatenated: http://s3.amazonaws.com/2008/09/javascript.mp4 (178 MB).

Yeah, those are awesome. I especially like the history of javascript in the first talk.

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)

Thanks for the review, I've been thinking if I should buy it, will now ;)

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

You can do exactly the same thing in Lua, too.

Scheme with C syntax and the associative array (nee object literal) as the basic datatype. It's a powerful setup.

Anyone knows of a JavaScript debugger that would display closures? It's seems kind of rough not to be able to see your "private" variables.

You should be able to watch closures in Firebug within the scope of the function using breakpoints.

Using closures really hides them.

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!

well I have read Apress JavaScript Design patterns by dean edwards(base2) and JavaScript techniques by Resig..

They do have overlapping content at times but surely helped me to understand static vs instance methods/prototype vs object.

One of the books clearly mentions how JavaScript is different than other languages. i.e. helps to understand reference/how chaining works( jQuery)

And once I read them I went back to ejohn.org and reread his posts. I can understand them better now :)

I don't get what's the point. What does it matter if a variable is private? This is not a prison, if you want a private variable, just don't use it.

Why go through all that hoopla?

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.

Ah well. I never liked javascript ;)

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.

I don't think it's clicked for you yet.

And when you say this:

"private" has a standardized meaning in pretty much all OOP languages

don't you mean "in C++ and Java"? Because Ruby's private is significantly different.

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.

I'll simply admit my own ignorance, I guess.

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

Reply on news.ycombinator.com