I do the IIFE (immediately invoked function expression) when class instances 
share a variable that I don't want to simply hang from the class constructor.

I also use !function these days instead of ;(function.  Although I will use 
;(function if the function is sad and squinty.

So:

var Foo = new Class({})
Foo.shared = {};

becomes

!function (){
  var privateShared = {}
  var Foo = this.Foo = new Class({})
  Foo.publicShared = {}
}.call(this)

this.Foo is to assign it to the context, which is probably window, otherwise 
it's trapped and you couldn't use it outside the IIFE.  var Foo at first is so 
I don't have to do this.Foo inside the IIFE if I need to assign something to it.

When writing MooTools, I use MooTools conventions / whitespace / etc.

When doing my own stuff, I do whatever I feel like. I enjoy experimenting with 
coding style and whitespace, makes you freak out less when you work on somebody 
else's code.

It's silly to think your style is the "best" or even "right."


On May 16, 2011, at 9:57 AM, אריה גלזר wrote:

> My 2 cent - I regularly patch packages together into one file, and some are 
> not my code. prefixing my closures with semicolon does come with any 
> significant cost (in fact, if you want, you can do
> 
> +function(){
> 
> }.apply(this);
> 
> and then you're even saving bytes). my point is that I don't trust other 
> people's code to be properly structured.  
> 
> On Mon, May 16, 2011 at 6:24 PM, Arian Stolwijk <[email protected]> wrote:
> That is what MooTools does, however there are some other opinions about it.
> 
> 
> On Mon, May 16, 2011 at 4:58 PM, Philip Thompson <[email protected]> 
> wrote:
> IMO, you shouldn't have to deal with prefixing the anonymous function (or 
> other statements) with a semi-colon. If you're the one writing the code, you 
> *know* what will work when you compress your own code. I know that some 
> compressors are more forgiving than others (e.g., YUI), but I believe it 
> comes down to writing code properly. You wouldn't leave a plus sign off of 
> your addition statement (for lack of a better analogy). Why not properly end 
> all your statements with semi-colons?
> 
> (function () {
>     var myVar = 'hi';
>     ...
> })();  // Add the semi-colon here
> 
> var Pizza = {
>     isGood: function () { return true; }
> };   // Add the semi-colon here
> 
> My $0.02. Happy coding.
> 
> ~Philip
> 
> On Sun, May 15, 2011 at 2:32 PM, Rolf -nl <[email protected]> wrote:
> Thanks for the quick reply. I understood about closures and keeping
> things private, but got sort of confused where I saw usage of:
> 
> (function(){
> 
> var hello = this.hello = 'yo';
> 
> and nowhere hello was used down in the code. But I think it could be
> there just as a standard anyway so I you would edit the code you don't
> have to think about it and you could just use 'hello' somewhere as you
> already defined it.
> 
> })()
> 
> about the ;function or !function etc. thanks for clearing up that
> chars like + or ~ would also 'work' -- again, I understood from
> reading elsewhere that people suggested the compressor would be wrong
> and should be looked at if the extra ! or ; before the parenthese was
> necessary to prevent errors (since trailing semi colons are not
> required). But still I would see it being used inside files which made
> me frown my eyebrows again.
> 
> 
> 
> On May 15, 8:36 pm, Arian Stolwijk <[email protected]> wrote:
> > You should read about closures.
> >
> > They help to prevent putting all kind of variables public.
> >
> > so you can wrap it with in a closure, or self-invoking-function, there are
> > several names and methods, but the basic example used in MooTools is:
> >
> > (function(){
> >
> > var private = 'yo';
> >
> > })();
> >
> > alert(private); // throws error
> >
> > But we don't want to put everything privately, but want to make it
> > public. Fortunately we can just put something on the window object. The
> > window object is equal to `this` in the browser:
> >
> > console.log(window == this);
> >
> > This is also true in closures:
> >
> > (function(){
> >
> > this.hello = 'yo';
> >
> > })();
> >
> > console.log(window.hello, this.hello, hello); // yo
> >
> > For better compression  you can do something like this:
> >
> > (function(){
> >
> > var hello = this.hello = 'yo';
> >
> > // now we can use hello here, which is private, instead of this.hello every
> > thime
> >
> > })();
> >
> > In 1.3.1 and in PowerTools .call(this) was used. .call and .apply work like
> > bind, but also execute the function. So here the inner this was set to the
> > outer this, which was still window. This supposed to fix something in some
> > fancy environments, but didn't work in node.js after all, since this refers
> > to something else there and not the global object.
> >
> > There are also other variants to fix nasty errors with compressing, when the
> > last ; is forgotten, see this example, which works ok
> >
> > (function(){
> >
> > })()
> > (function(){
> > })()
> >
> > but when we compress:
> >
> > (function(){})()(function(){})()
> >
> > which errors.
> >
> > Putting some other char before the (function(){, like a !, ; ~, + or
> > whatever solves this problem.
> >
> > I hope this helps you and I've given you some pointers to search further.
> >
> >
> >
> > On Sun, May 15, 2011 at 8:16 PM, Rolf -nl <[email protected]> wrote:
> > > Looking at Moo's source and following the syntax and code style rules
> > > I was (in the past) used to do it like:
> >
> > > var myClass = new Class({
> > > });
> >
> > > then people started to wrap it and adopted:
> >
> > > (function(){
> >
> > >    var myClass = new Class({
> > >    });
> >
> > > })();
> >
> > > or an alternate ending for the wrap (like in cpojer's powertools):
> >
> > > }).call(this);
> >
> > > ryan florence is dropping trailing semi-colons in his (non mootools
> > > released) js code (which is fine I think, others can disagree) but
> > > starting code with a semi-colon before every parenthese like:
> >
> > > ;(function(){
> > > })();
> >
> > > and I also noticed this:
> >
> > > var myClass = this.myClass = new Class({
> > > });
> >
> > > since when are we also adding this.myClass? What is the benefit, why
> > > is it important?
> >
> > > Ok, what I'm trying to say is that I see sort of the use of all of
> > > this and I understand what it does, but I don't fully 'get' the path
> > > to follow or why I would do it one way or the other.
> >
> > > Maybe someone can enlighten us here on the list or maybe a blog post
> > > to take away some confusion.
> 
> 
> 
> 
> 
> -- 
> Arieh Glazer
> אריה גלזר
> 052-5348-561
> http://www.arieh.co.il
> http://www.link-wd.co.il
> 

Reply via email to