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
<[email protected]> 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
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
