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
Summary:
Update "Object Literal Extensions" [1] to integrate with constructor
parameters for concise instance initialization.
Details:
function f (a, !~this.b, this.c:= 1) {
g(a);
}
// 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};
g(a);
}
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
[1]
http://wiki.ecmascript.org/doku.php?id=strawman:basic_object_literal_extensions
Cheers,
Sean Eagan
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
