Garrett,
> >
> > I think Google doesn't use closures for private variables because of
> > the small performance penality it has (variables are searched up the
> > scope-chain). As far as I know they're utilizing Closure Compiler's
> > ability to guard private members (using @private):
> >
> <touchy>
> A more likely explanation is that the authors of Closure COmpiler do
> not understand [[Scope]].
> </touchy>
>
>
I have been reading through Closure: The Definitive Guide at a leisurely
pace, and I can confirm that they do suggest you use closures very
infrequently because of problems with closures and memory leaks (mostly in
older browsers). It seems to me that they prefer to use a combination of
partial/curry/bind on functions which take many parameters. This means that
the only closure that gets created is inside the partial/curry/bind
definition, which probably has less in its scope than the closure that would
be created if you just made a function literal wherever you had previously
used partial/curry/bind.
That last sentence was a bit of a mouthful, and if I am not writing very
clearly, please let me know and I can try again :)
> /**
> > * A simple private memeber of goog.
> > * @private
> > * @type {String}
> > */
> > goog._secret = "cannot be accessed directly from outside";
> >
> Running that example, comments and all, through CC at:
> http://closure-compiler.appspot.com/home
>
> The result is:
> | goog._secret="cannot be accessed directly from outside";
>
> Identifier `_secret` can be accessed directly from outside.
>
> Similarly for the example in the article you've linked, which states
> about an example:
> "The compiler will ensure that the private member _birthDay isn’t read
> or write through out the whole application."
>
> When I run that example through CC, I get the output:
>
> function User(){this._birthDay=new
> Date}User.prototype.getBirthYear=function(){return
> this._birthDay.getYear()};var me=new
> User;document.write(me.getBirthYear().toString());
>
> The _birthDay property is not private:
> | var u = new User;
> | alert(user._birthDay);
>
> The `_birthDay` property is not private at all.
>
>
Its not really private, no. However, if you tell the closure compiler to use
"advanced mode", and use the annotations "properly", the compiler should
yell loudly at you if you try to fiddle with these psuedo-private members in
code that you are compiling. In this sense, yes, they kind of are private.
However, if I were to open web inspector or firebug on a page that loaded
that script, I would be able to mess with the "private" members. Hence the
psuedo.
I'm not sold on coding this way, or really feel its the Right Way, but I
just want to share the perspective that the collected Closure library and
tool set has. Me, I like the elegance of closures to encapsulate private
state. However it is always good to check out new
paradigms/points-of-view/etc. Always keep an open mind :)
FWIW, I think you are spot on WRT "letting the closure compiler make you a
samurai". It seems people everywhere want to be sold snake oil because no
one wants to actually buckle down and work to learn the core concepts...
Take it easy,
_Nick_
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/[email protected]/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/[email protected]/
To unsubscribe from this group, send email to
[email protected]
