On Mon, Mar 19, 2012 at 5:42 PM, Peter van der Zee <[email protected]> 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}
> };
>
> var obj = {
> a: null,
> get a() {return this.a},
> set a(v) {this.a=v}
> };
>
I just had a "with" flashback. ;)
>
> 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
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
