

This is the page that made doing OOP in Javascript click for me. - edw519
http://www.crockford.com/javascript/private.html

======
axod
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

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

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

~~~
tlrobinson
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)

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

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

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

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

------
malkia
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))

------
deafmetal
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!

------
morbidkk
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 :)

------
ars
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?

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

------
trezor
_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 ;)

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

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

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

