Would it make sense to cover that use case via some kind of early completion
value return (e.g. a break with a completion value). That could then also be
used as a return substitute for TCP blocks.
let obj = do {
let a;
break : {get a() {return a},
set a(v) {a=v}
}
}
Not exactly a character-saving solution, though.
On Mar 19, 2012, at 21:13 , Allen Wirfs-Brock 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
>
--
Dr. Axel Rauschmayer
[email protected]
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
