The Private Names strawman currently combines a new runtime capability (using both strings and private names as keys in objects) with several new syntactic constructs (private binding declarations, #.id).  At the March meeting, I recall there was some support for the idea of separating these two aspects, and exposing the runtime capability also as a library that could be used in 'text/javascript'.

I added a comment to the Private Names strawman page to suggest how this could be done.  The runtime behavior of the proposal is the same, but in addition, a  library function "Object.createPrivteName(name)" is added which provides direct access to the internal CreatePrivateName abstract operation.  This allows the use of private names in a more verbose form, but without needing new syntax - similar in spirit to the ES5 Object.* operations.
Borrowing an example from the current proposal to illustrate:

Using 'text/harmony' syntax:
      function Point(x,y) {
         private x, y;
         this.x = x;
         this.y = y;
         //... methods that use private x and y properties
      }
      var pt = new Point(1,2);

Using 'text/javascript' syntax:
      function Point(x,y) {
         var _x = Object.createPrivateName("x");
         var _y = Object.createPrivateName("y");
         this[_x] = x;
         this[_y] = y;
         //... methods that use private _x and _y properties
      }
      var pt = new Point(1,2);

There seem to be several benefits to this:
(1) The private name capability can be made available to 'text/javascript'
(2) The feature is easily feature-detectable, with a fallback of using '_'-prefixed or similar pseudo-private conventions
(3) The core functionality can potentially be agreed upon and implemented in engines earlier than full new syntax

Luke

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110518/d965ad25/attachment.html>

The Private Names strawman currently combines a new runtime capability (using both strings and private names as keys in objects) with several new syntactic constructs (private binding declarations, #.id).  At the March meeting, I recall there was some support for the idea of separating these two aspects, and exposing the runtime capability also as a library that could be used in 'text/javascript'.

I added a comment to the Private Names strawman page to suggest how this could be done.  The runtime behavior of the proposal is the same, but in addition, a  library function `Object.createPrivateName(name)` is added which provides direct access to the internal CreatePrivateName abstract operation.  This allows the use of private names in a more verbose form, but without needing new syntax - similar in spirit to the ES5 `Object.*` operations.
Borrowing an example from the current proposal to illustrate:

Using 'text/harmony' syntax:

      function Point(x,y) {
         private x, y;
         this.x = x;
         this.y = y;
         //... methods that use private x and y properties
      }
      var pt = new Point(1,2);

Using 'text/javascript' syntax:

      function Point(x,y) {
         var _x = Object.createPrivateName("x");
         var _y = Object.createPrivateName("y");
         this[_x] = x;
         this[_y] = y;
         //... methods that use private _x and _y properties
      }
      var pt = new Point(1,2);

There seem to be several benefits to this:

1. The private name capability can be made available to 'text/javascript'
2. The feature is easily feature-detectable, with a fallback of using '_'-prefixed or similar pseudo-private conventions
3. The core functionality can potentially be agreed upon and implemented in engines earlier than full new syntax

The Private Names strawman currently combines a new runtime capability (using both strings and private names as keys in objects) with several new syntactic constructs (private binding declarations, #.id).  At the March meeting, I recall there was some support for the idea of separating these two aspects, and exposing the runtime capability also as a library that could be used in 'text/javascript'.

I added a comment to the Private Names strawman page to suggest how this could be done.  The runtime behavior of the proposal is the same, but in addition, a  library function "Object.createPrivteName(name)" is added which provides direct access to the internal CreatePrivateName abstract operation.  This allows the use of private names in a more verbose form, but without needing new syntax - similar in spirit to the ES5 Object.* operations.
Borrowing an example from the current proposal to illustrate:

Using 'text/harmony' syntax:

      function Point(x,y) {
         private x, y;
         this.x = x;
         this.y = y;
         //... methods that use private x and y properties
      }
      var pt = new Point(1,2);

Using 'text/javascript' syntax:

      function Point(x,y) {
         var _x = Object.createPrivateName("x");
         var _y = Object.createPrivateName("y");
         this[_x] = x;
         this[_y] = y;
         //... methods that use private _x and _y properties
      }
      var pt = new Point(1,2);

There seem to be several benefits to this:

1. The private name capability can be made available to 'text/javascript'
2. The feature is easily feature-detectable, with a fallback of using '_'-prefixed or similar pseudo-private conventions
3. The core functionality can potentially be agreed upon and implemented in engines earlier than full new syntax