The premise was that there are situation where you want to group lexical
declarations and then use them in combination to generate a value. The do
operator is a way to do this. The fact that you might use a completely
different technique to generate a different value isn't very relevant.
More concretely I tried to eliminate superficial elements from my example. The
actual use case I had in mind was:
private a; //means: const a = Name.create();
var obj = {
@a: null, //or [a] if we stick with that notation for private named
property access
get a() {return this.@a},
set a(v) {this.@a=v}
};
written as:
let obj = do {
private a;
.{ @a: null,
get a() {return this.@a},
set a(v) {this.@a=v}
}
};
The original question from another thread is whether we need something like the
private declaration inside an object literal
On Mar 19, 2012, at 2:42 PM, Peter van der Zee wrote:
> 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}
> };
>
>
> 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
