re-using getters and setters in object literals

Allen Wirfs-Brock Allen.Wirfs-Brock at microsoft.com
Tue Aug 19 18:21:07 PDT 2008


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.

> -----Original Message-----
> From: es-discuss-bounces at mozilla.org [mailto:es-discuss-
> bounces at mozilla.org] On Behalf Of Brendan Eich
> Sent: Tuesday, August 19, 2008 5:31 PM
> To: Richard Cornford
> Cc: es-discuss at mozilla.org
> Subject: Re: 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:
>
> http://wiki.ecmascript.org/doku.php?id=proposals:getters_and_setters
>
> (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.
>
> /be
>
> _______________________________________________
> Es-discuss mailing list
> Es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss



More information about the Es-discuss mailing list