Dojo v. Crockford re privates

[Martin Rinehart]

The Dojo Style Guide suggests prepending an underscore to indicate a
"private" variable. Crockford says don't; JavaScript doesn't have
privates. Which should be the convention?

I'll vote first: Dojo. Crockford is correct, but I find his logic
broken. The prepended underscore says clearly "If we had 'private's
this would be one of them." That is useful information, conveyed
succinctly.

 

[David Mark]

The Dojo Style Guide suggests prepending an underscore to indicate a

The what Style Guide?

"private" variable. Crockford says don't; JavaScript doesn't have
privates. Which should be the convention?

Crockford is right.

I'll vote first: Dojo. Crockford is correct, but I find his logic
broken.

That is contradictory.

The prepended underscore says clearly "If we had 'private's
this would be one of them." That is useful information, conveyed
succinctly.

No, the use of such a convention typically betrays a poor design. If
you want/need a "private method" then don't expose it to the rest of
your code.

 

[slebetman]

The Dojo Style Guide suggests prepending an underscore to indicate a
"private" variable. Crockford says don't; JavaScript doesn't have
privates.

Actually Crockford says (and I paraphrase): Javascript has privates --
via closures. (Incidentally this sentiment is also repeated on
PerlMonks).

Which should be the convention?

function SomeConstructor () {
this._foo = function (){}; // is a convention
var foo = function (){}; // is really private
}

Both has its uses. If you want "pretend" privates (which is very
strongly advocated in Perl - don't prevent users from accessing
anything) then the _underscore convention says: you shouldn't touch
this, you can but then all bets are off. If you really want to prevent
others from accessing your methods then using a closure is your best
bet.

Then main problems with closures are that you can't inherit them and
you can't call them from functions added at a later date. For example:

var x = new SomeConstructor();
x.bar = function () {
foo() // this doesn't work
}

 

[David Mark]

Actually Crockford says (and I paraphrase): Javascript has privates --
via closures. (Incidentally this sentiment is also repeated on
PerlMonks).

Not sure why "PerlMonks" would comment on ECMAScript implementations.
Regardless, "privates" in closures should not start with underscores.

function SomeConstructor () {
  this._foo = function (){}; // is a convention

It is also silly.

  var foo = function (){};   // is really private

And clearly requires no underscore to differentiate it from the
object's methods (which are always "public.")

}

Both has its uses. If you want "pretend" privates (which is very
strongly advocated in Perl - don't prevent users from accessing

PERL again? Never mind that.

anything) then the _underscore convention says: you shouldn't touch
this, you can but then all bets are off. If you really want to prevent
others from accessing your methods then using a closure is your best
bet.

You answered your own question.

Then main problems with closures are that you can't inherit them and

I don't know what that means (my guess is nothing.)

you can't call them from functions added at a later date. For example:

var x = new SomeConstructor();
x.bar = function () {
  foo() // this doesn't work

A simple answer is that bar needs to be "private" or foo needs to be
"public." There are other design options for sharing "private
members" at the "class level." Richard Cornford published some
interesting articles about this on his site, but I can't seem to find
them (or it) at the moment.

[snip]

 

[Martin Rinehart]

David, I see that you don't like leading underscores but I don't see
your answer to my suggestion that they are a useful method of
communicating intent. If I see "attr" in another programmer's code
I'll use it. If I see "_attr" I'll look for getAttr() and setAttr().
Not finding them I'll think carefully before using "attr".

I also see that you have a negative opinion on Dojo. I've no
experience with it, except that I appreciate it when someone takes the
time to write a conventions document. Could you fill us in? Thx.

Martin

 

[Thomas 'PointedEars' Lahn]

What about protected methods? A base constructor can have "public"
methods in his prototype, as well as methods that derived objects should
be able to use, but that shouldn't be called from outside.

Have you succeeded in creating such a method yet?


PointedEars

 

[John G Harris]

The Dojo Style Guide suggests prepending an underscore to indicate a
"private" variable. Crockford says don't; JavaScript doesn't have
privates. Which should be the convention?

I'll vote first: Dojo. Crockford is correct, but I find his logic
broken. The prepended underscore says clearly "If we had 'private's
this would be one of them." That is useful information, conveyed
succinctly.

Why not make it really annoying to use a private variable. Give them
awkward names such as
PRIVATE_x

John