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]

Re: Dojo v. Crockford re privates

On Nov 5, 2:40 pm, Martin Rinehart <MartinRineh... @gmail.comwrote :

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.

[Conrad Lender]

Re: Dojo v. Crockford re privates

On 2008-11-05 21:23, David Mark wrote:

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

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.


- Conrad

[slebetman]

Re: Dojo v. Crockford re privates

On Nov 6, 3:40 am, Martin Rinehart <MartinRineh... @gmail.comwrote :

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]

Re: Dojo v. Crockford re privates

On Nov 5, 4:20 pm, slebetman <slebet...@gmai l.comwrote:

On Nov 6, 3:40 am, Martin Rinehart <MartinRineh... @gmail.comwrote :
>

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

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

>

Which should be the convention?

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

Re: Dojo v. Crockford re privates

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]

Re: Dojo v. Crockford re privates

Conrad Lender wrote:

On 2008-11-05 21:23, David Mark wrote:

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

>
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
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>

[Conrad Lender]

Re: Dojo v. Crockford re privates

On 2008-11-06 19:25, Thomas 'PointedEars' Lahn wrote:

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

No. I've been using public methods (which can be inherited), and marked
them with a leading underscore. This makes them "protected" only by
convention, of course. Is there a better way to do it?


- Conrad

[John G Harris]

Re: Dojo v. Crockford re privates

On Wed, 5 Nov 2008 at 11:40:38, in comp.lang.javas cript, Martin Rinehart
wrote:

>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
--
John Harris