> Learn interleaved reply; do not top post. Ok, my friend :)
> <touchy> > A more likely explanation is that the authors of Closure COmpiler do > not understand [[Scope]]. > </touchy> Well I can't comment on that. There was a blog post from one of the GMail team members where he talks about why they're using _private members on simple objects instead of the module pattern. The main point was the performance overhead of object creation if I remember well. http://jsperf.com/closure-vs-member > 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. > Where "outside" means any JS file other than the current one. > 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." > > The `_birthDay` property is not private at all. > And his next sentence is: "Only code in the same JS can access objects that are marked @private." I gotta admit this aspect of @private wan't clear for me too. I'm not using Google CC in production after all. But it seems that Google is using the Java-like "one file, one object/module" organization. Also see the docs: http://code.google.com/closure/compiler/docs/js-for-compiler.html "Marks a member as private. Only code in the same file can access global variables and functions marked @private." >> You can read more about Google CC OOP features at: >> http://calendar.perfplanet.com/2010/coding-better-object-oriented-javascript-with-closure-compiler/ >> > Does he explain what that code does? No! He just says its all to > confusing and instead: > "Let Closure Compiler make you a JavaScript Samurai!" > > I mentioned javascript library blog FUD yesterday and this is a fine > example. They want to make cross browser scripting seem so scary and > complicated. This stuff is not that hard. This is a tricky example, > here but let me break that down and you may likely have one up on the > author of this article. > Instead of explaining what that toy example does, the author goes on > to tell you you need Closure Compiler to be a "Samurai". Self claimed "Ninjas" are common nowadays... :) Don't get me wrong I didn't want to suggest anything with my post. I was rather trying to answer why Google may use one of them. - Balázs > Garrett >> >> 2010/12/16 bawigga <[email protected]>: >>> What is the correct nomenclature for the following ways of writing JS. I >>> understand how each example works, but I don't know how to put the >>> following >>> patterns into words. I also don't know when it's best to use one pattern >>> over the other (perhaps just preference)? >>> I personally prefer ex 2/3 as I feel as though it keeps my code a lot >>> cleaner, and easier to maintain. It would seem ex1 doesn't really help in >>> code maintainability as you still have a bunch of seemingly random >>> unrelated >>> functions within a single namespace. >>> I also found that the google closure lib uses ex 1, and jquery seems to >>> use >>> ex 2/3. Why would they choose one over the other? >>> >>> Google Closure - >>> http://code.google.com/p/closure-library/source/browse/trunk/closure/goog/base.js?r=544 >>> - namespace pattern? >>> jQuery - http://code.jquery.com/jquery-1.4.4.js - using object literal? >>> >>> // ex 1 (namespace pattern?) >>> goog.a = function() { >>> //do something >>> }; >>> goog.b = function(){ >>> //do something >>> }; >>> // ex2 (module pattern?) >>> goog = (function(){ >>> return { >>> a: function(){ >>> // do something >>> }, >>> b: function() { >>> // do something >>> } >>> }; >>> })(); >>> // ex 3 (literal pattern?) >>> goog = { >>> a: function(){ >>> // do something >>> }, >>> b: function() { >>> // do something >>> } >>> } >>> >>> -- >>> 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] >>> >> >> -- >> 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] >> > > -- > 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] > -- 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]
