Proposal: Concise instance initialisation

François REMY fremycompany_pub at
Sat May 21 03:11:31 PDT 2011

this.c:= 1 looks like an error. If the intent was to set the "c" property to 
a constant, it should not be a function' parameter. If, as I understood, you 
have set a default value for the c parameter, what if you didn't specify 
that value? I think it shows that the current 'readonly' syntax (aka :=) 
should be reconsiderated, because it's the only one that's postfix (and the 
only one who need an equality symbol after it, which makes it difficult to 
exted its use to other locations, as this exemple puts in light).

    PROPOSAL: Prefix readonly flag (or postfix everything)

The problem I see is that it still *may* be non-extendable to other places 
(i.e. traditionnal assignations) because the ! symbol is already used as the 
"NOT" operator.

Another option would be to use only two symbols (I used õ and ñ here, but we 
could imagine using something different) and using them as flags :

ñ       not enumerable
õñ     not writable
õõñ   not configurable
õññ   not writable AND not configurable

    PROPOSAL: Extension to all assignations (here using õñ flags)

        function setParent(a) {
            a._hasParent ñññ= true;
            a.parent õññ= this;

        function ReadOnlyPoint(this.x õññ, this.y õññ) {} // will be rare in 
true code

        function setTag(obj, value) { obj.__tag ñ= value; }

        function getTag(obj) { return obj.__tag; }

Another beautiful combination could be ~ and :

        function setParent(a) {
            a._hasParent ~~~= true;
            a.parent :~~= this;

        function ReadOnlyPoint(this.x :~~, this.y :~~) {} // will be rare in 
true code

        function setTag(obj, value) { obj.__tag ~= value; }

        function getTag(obj) { return obj.__tag; }

Please note that in the case of traditionnal assignations, the ! could be 
used because the expression before an assignation symbol should not contains 
a NOT operator anyway. It could just be confusing to see things like 
"!#obj.boolProperty=!objToCopy.boolProperty" while "obj.boolProperty õññ= 
!objToCopy.boolProperty" seems clearer (to me, at least). At least, it makes 
it clear that it's not a simple assignation but a more complex one.

(Maybe a more global remark:)
I know the current mainstream seems to be "please, less characters to type", 
but I'm sincerely under the impression that the more we go in that direction 
the less clear the syntax becomes and the more possible confusions are 
introduced. Maybe should we include in every proposal more than one flavor 
(and a least a verbose one) so that the different specials chars don't 
overlap between all proposals. At the end, the comitee would decide which 
proposals will get a short syntax and which will get a longer one, in order 
to avoid different meaning for a same keyword (or symbol) when it can be 
confusing (and to maximise the usage of the short syntax in the most 
promising proposals while less used pattern would get longer syntax).

-----Message d'origine----- 
From: Sean Eagan
Sent: Saturday, May 21, 2011 10:10 AM
To: es-discuss
Subject: Proposal: Concise instance initialisation


Update "Object Literal Extensions" [1] to integrate with constructor
parameters for concise instance initialization.


function f (a, !~this.b, this.c:= 1) {

// results in f's [[Construct]] ( but not [[Call]] ) behaving like:

function f (a, b, c = 1) {
  Object.defineProperty(this, "b", {configurable: false, enumerable:
false, writable; true, value: b};
  Object.defineProperty(this, "c", {configurable: true, enumerable:
true, writable; false, value: c};

Grammar changes to [1] :

FormalParameter :
  FormalParameterPrefixOpt Identifier FormalParameterInitialiserOpt
  // possibly integrate with destructuring and/or rest parameters as well

FormalParameterPrefix :
  PropertyPrefixOpt thisOpt . // "this" is optional

FormalParameterInitialiser :
  :Opt Initialiser


Sean Eagan
es-discuss mailing list
es-discuss at 

More information about the es-discuss mailing list