By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,628 Members | 1,696 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,628 IT Pros & Developers. It's quick & easy.

Dojo v. Crockford re privates

P: n/a
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.
Nov 5 '08 #1
Share this Question
Share on Google+
8 Replies


P: n/a
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.
Nov 5 '08 #2

P: n/a
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
Nov 5 '08 #3

P: n/a
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
}
Nov 5 '08 #4

P: n/a
On Nov 5, 4:20*pm, slebetman <slebet...@gmail.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]

Nov 5 '08 #5

P: n/a
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
Nov 6 '08 #6

P: n/a
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>
Nov 6 '08 #7

P: n/a
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
Nov 7 '08 #8

P: n/a
On Wed, 5 Nov 2008 at 11:40:38, in comp.lang.javascript, 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
Nov 11 '08 #9

This discussion thread is closed

Replies have been disabled for this discussion.