`static` keyword from C/C++ as own closured var declaration

Allen Wirfs-Brock allen at wirfs-brock.com
Tue Nov 23 10:30:55 PST 2010


-----Original Message----- 
From: David Herman
Sent: Tuesday, November 23, 2010 1:07 AM
To: Bga
Cc: es-discuss at mozilla.org
Subject: Re: `static` keyword from C/C++ as own closured var declaration

Allen suggested something like this in the September meeting. One issue 
people had with it was that it adds another violation of the equivalence 
between a statement <stmt> and (function()<stmt>)(), which is a refactoring 
hazard. Put differently, if you have some code with "static" declarations in 
it, you can't wrap the code in a function body without breaking the code, 
which makes it brittle.

Separate from that, I also don't really see how the idea really buys you all 
that much. The analogy to C is only so helpful, since C doesn't have nested 
functions (and static therefore always lifts to global scope), so mostly it 
just reads to me like a rather obscure way of saying "oops, I meant to bind 
this over there."

Dave
--------------------------------

I agree that it doesn't appear to buy you much with simple, scalar valued 
statics like shown in these examples.  However, I think it is quite 
different if you look at actual JavaScript abstraction patterns.  For 
example:

function pointFactory(x,y) {
   static protoPoint = {
      moveTo: function (x,y) {...},
      distance: function (aPoint) {...},
      plus: function (aPoint) {...},
      minus: function(aPoint) {...),
      //etc.
   };
   var it=Object.create(protoPoint);
   it.x=x;
   it.y=y;
   return it;
   //I really want to just say: return {<prototype:protoPoint>, x:x,y:y};
}

To me seems much more readable than:

let pointFactory = function() {
   let protoPoint = {
      moveTo: function (x,y) {...},
      distance: function (aPoint) {...},
      plus: function (aPoint) {...},
      minus: function(aPoint) {...),
      //etc.
   };
   return function (x,y) {
      var it=Object.create(protoPoint);
      it.x=x;
      it.y=y;
      return it;
   }
}();

Everybody on this list is quite confortable with using higher-order 
functions to express such abstractions.  This isn't the case for the vast 
majority of JavaScript programmers and I'm not sure it will ever be the 
case.  Instead, the pattern that would more likely be written as:

var protoPoint = {
   moveTo: function (x,y) {...},
   distance: function (aPoint) {...},
   plus: function (aPoint) {...},
   minus: function(aPoint) {...),
   //etc.
};

function pointFactory(x,y) {
   var it=Object.create(protoPoint);
   it.x=x;
   it.y=y;
   return it;
}

which breaks encapsulation.  It is also highly likely that many JavaScript 
programmer would just code it as:

function pointFactory(x,y) {
   var protoPoint = {
      moveTo: function (x,y) {...},
      distance: function (aPoint) {...},
      plus: function (aPoint) {...},
      minus: function(aPoint) {...),
      //etc.
   };
   var it=Object.create(protoPoint);
   it.x=x;
   it.y=y;
   return it;
}

without realizing that they aren't getting a shared prototype object. 
Teaching them that they should make shared prototype objects "static" seems 
like it would be much more likely to sink in than trying to teach any of the 
other more complex patterns.

The reason I originally proposed this use of static, is that I've personally 
found  that  the "own" variable pattern to be something that comes up 
frequently when defining abstractions using JavaScript.  Making it explicit 
would make it easier to both write and read such definitions.

Allen 



More information about the es-discuss mailing list