YAWSI: an identity unary operator

Peter van der Zee ecma at qfox.nl
Mon Mar 19 14:42:39 PDT 2012


As long as we're bikeshedding; none of your examples look as clean to
me as the original. If you're dead set on fixing this, try changing
the this keyword...

var a;
var obj = {
  get a() {return a},
  set a(v) {a=v}
};

var obj = {
  a: null,
  get a() {return this.a},
  set a(v) {this.a=v}
};

This looks much cleaner to me than any of the other examples.

(Getters and setters are non-transferable, so they'll always have a
context, right?)

- peter

On Mon, Mar 19, 2012 at 9:13 PM, Allen Wirfs-Brock
<allen at wirfs-brock.com> wrote:
> (Yet Another Wacky Syntax Idea)
>
> Here is a relatively common coding pattern:
>
> var a;
> var obj = {
>   get a() {return a},
>   set a(v) {a=v}
> };
>
> Often the intent is that the variable a should only be used within the object literal.  The block scoping with let and do operator will allow the variable and object literal to be group in this manner:
>
> let obj  = do {
>    let a;
>    ({get a() {return a},
>      set a()v) {a=v}
>    })
> }
>
> Unfortunately, the object literal has to be enclosed in parentheses because an expression statement cannot begin with an object literal.  The same would be the case if a function expression was involved rather than an object literal.
>
> Parens are annoying because you have to remember to close them and match them if any additional nesting is involved.
>
> With completion reform, do expressions, and broader use of  blocks that produce values we should expect to see more situations where an ExpressionStatement needs to start with an object literal or function expression. It would be nice to have some way to do this that does not require parentheses.
>
> Prefix the expression with an unary operator is sufficient to disambiguate such expression but unfortunately all of the existing unary operators perform conversions that would invalidate the value.  However, a new unary operator whose semantics was to simply return its operand value would do the job nicely.   Both . and = seem like good candidates for such an operator but any operator symbol that is not currently used in a unary form would be a possibility:
>
> let obj  = do {
>    let a;
>    ={get a() {return a},
>       set a(v) {a=v}
>    }
> }
>
> let obj  = do {
>    let a;
>    .{get a() {return a},
>       set a(v) {a=v}
>    }
> }
>
> let obj  = do {
>    let a;
>    ^{get a() {return a},  //probably my favorite, but that may just be a leakage from my Smalltalk background...
>        set a(v) {a=v}
>    }
> }
>
> let obj  = do {
>    let a;
>    |{get a() {return a},
>       set a(v) {a=v}
>    }
> }
>
> let obj  = do {
>    let a;
>    /{get a() {return a},
>       set a(v) {a=v}
>    }
> }
>
> let obj  = do {
>    let a;
>    *{get a() {return a},
>       set a(v) {a=v}
>    }
> }
>
> What about ASI?  Adding a unary form of an existing binary operator doesn't introduce any new issues or break/change existing code:
>
> x
>    ={ };
>
> parses as an assignment to x even if = is given a new meaning as a unary operator.
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss


More information about the es-discuss mailing list