re-using getters and setters in object literals
On Aug 19, 2008, at 4:55 PM, Richard Cornford wrote:
In the current ES 3.1 draft we have:-
PropertyAssignment : PropertyName : AssignmentExpression get PropertyName ( ) { FunctionBody } set PropertyName ( PropertySetParameterList ) { FunctionBody }
- in which I don't see any provision for re-using function objects as getters and setters. That is, there is no mechanism for defining/creating a function object elsewhere and then using it as a getter or a setter for an object literal. Has that possibility been rejected, or never raised?
I've raised it, since my original getter/setter implementation (1998
era) allowed this:
function sharedGetter() { /* voluminous code here */ }
var obj = { prop1 getter: sharedGetter, prop2 getter: sharedGetter, ... };
The getter: and setter: punctuator-sequences consisted of two tokens;
getter and setter were only contextually reserved. There were getter=
and setter= assignment operators, too; these have been superseded in
SpiderMonkey and Rhino by defineGetter and defineSetter.
The inability to share a getter or setter in the syntax that replaced
the above:
var obj = { get prop1() { return sharedGetter(); }, get prop2() { return sharedGetter(); }, ... };
was indeed noted here:
(look for my comment dated 2007/05/04 12:21). Note also the loss of
string and number property names.
As it stands the algorithms require a new function object be created for each getter and setter with each object creation process that following from the use of an object litters. This strikes me as possibly being less than optimal in some circumstances, and certainly would preclude the possibility of using functions returned from the - bind - method or inner functions that exploit closures as getters and setters in object literals (except the closures formed by the evaluation of the PropertyAssignments).
I imagine that the productions for these possibilities would be something like:-
get PropertyName : AssignmentExpression set PropertyName : AssignmentExpression
- where a TypeError would be thrown in the event that AssignmentExpression did not evaluate as a function object following GetValue (i.e. is not an object or does not have a [[Call]] method). With AssignmentExpression used here to allow, for example, the return value from a function call to provide the function refence value used as the getter/setter (or even - new Function( .. ) -).
Richard Cornford.
I'm in favor, for ES-Harmony if not ES3.1.
I could be convinced on this one. When we put the current syntax into the 3.1 spec we were following the 3 out of 4 implementations already allow it rule. We could potentially relax that rule in this case and include the proposed extended syntax.
I have one slight reservation. I really like object literals, they are the one declarative way that the language provides for defining objects. I think that they could become one of the foundation pieces that some of the "harmony" functionality gets built upon. If that is the case, I can image other reasonable extensions to object literals syntax that we might want to consider. So, should we hold off this extension and think it through in the Harmony context or should we just put it in now with a reasonable degree of confidence that we won't regret the decision.
Brendan Eich wrote
On Aug 19, 2008, at 4:55 PM, Richard Cornford wrote:
In the current ES 3.1 draft we have:-
PropertyAssignment : PropertyName : AssignmentExpression get PropertyName ( ) { FunctionBody } set PropertyName ( PropertySetParameterList ) { FunctionBody }
- in which I don't see any provision for re-using function objects as getters and setters. That is, there is no mechanism for defining/creating a function object elsewhere and then using it as a getter or a setter for an object literal. Has that possibility been rejected, or never raised?
I've raised it,
So that means rejected. A pity.
since my original getter/setter implementation (1998
era) allowed this:function sharedGetter() { /* voluminous code here */ }
var obj = { prop1 getter: sharedGetter, prop2 getter: sharedGetter, ... };
The getter: and setter: punctuator-sequences consisted of two tokens; getter and setter were only contextually reserved. There were getter= and setter= assignment operators, too; these have been superseded in SpiderMonkey and Rhino by defineGetter and defineSetter.
The - Object.defineProperty - method seem to allow for assigning getters and setters using any function reference, so re-using functions is possible. (And that method will throw a TypeError if the getter/setter values are not callable.) So it is not that the action cannot be taken in ES 3.1, it is just going to mean using an object literal and then passing the result through - Object.defineProperty - (possibly repeatedly) in order to assign the function(s). That is going to be pretty messy in comparison to being able to do it all inside one object literal.
The inability to share a getter or setter in the syntax that replaced the above:
var obj = { get prop1() { return sharedGetter(); }, get prop2() { return sharedGetter(); }, ... };
was indeed noted here:
(look for my comment dated 2007/05/04 12:21). Note also the loss of
string and number property names.
Well string and number literal property names (even for getters and setters) appear to be in ES 3.1, which is a good thing IMO.
<snip>
I'm in favor, for ES-Harmony if not ES3.1.
:)
Richard Cornford.
In the current ES 3.1 draft we have:-
PropertyAssignment : PropertyName : AssignmentExpression get PropertyName ( ) { FunctionBody } set PropertyName ( PropertySetParameterList ) { FunctionBody }
As it stands the algorithms require a new function object be created for each getter and setter with each object creation process that following from the use of an object litters. This strikes me as possibly being less than optimal in some circumstances, and certainly would preclude the possibility of using functions returned from the - bind - method or inner functions that exploit closures as getters and setters in object literals (except the closures formed by the evaluation of the PropertyAssignments).
I imagine that the productions for these possibilities would be something like:-
Richard Cornford.
In the current ES 3.1 draft we have:- PropertyAssignment : PropertyName : AssignmentExpression get PropertyName ( ) { FunctionBody } set PropertyName ( PropertySetParameterList ) { FunctionBody } - in which I don't see any provision for re-using function objects as getters and setters. That is, there is no mechanism for defining/creating a function object elsewhere and then using it as a getter or a setter for an object literal. Has that possibility been rejected, or never raised? As it stands the algorithms require a new function object be created for each getter and setter with each object creation process that following from the use of an object litters. This strikes me as possibly being less than optimal in some circumstances, and certainly would preclude the possibility of using functions returned from the - bind - method or inner functions that exploit closures as getters and setters in object literals (except the closures formed by the evaluation of the PropertyAssignments). I imagine that the productions for these possibilities would be something like:- get PropertyName : AssignmentExpression set PropertyName : AssignmentExpression - where a TypeError would be thrown in the event that AssignmentExpression did not evaluate as a function object following GetValue (i.e. is not an object or does not have a [[Call]] method). With AssignmentExpression used here to allow, for example, the return value from a function call to provide the function refence value used as the getter/setter (or even - new Function( .. ) -). Richard Cornford.