A shorthand for Object.defineProperty?

Axel Rauschmayer axel at rauschma.de
Mon Jun 20 12:40:35 PDT 2011


> Anyway, my point is that decorators in front of functions and classes or other declarative forms work. In front of every property assignment in an object literal? Not so much.

The defaults outlined in “Object Literal Extensions” should work well, I especially like the shorter syntax for methods. What other needs are there? @const (=non-configurable and non-writable) and @private? That would move things a little more into the direction of Java, but I wouldn’t mind that. A little more verbose, yes, but one would also immediately understand what is going on.

> It may be that we require @decorators to start on a new line (with leading horizontal space allowed, of course), in order to enable @ as an operator in expressions where [no LineTerminator here] would apply to the left of the @.

That makes sense. I always format my code like this, anyway. Syntax coloring displays them in gray which greatly minimizes *perceived* clutter.

> What are the few special characters that you can handle, right now, as additions mooted for JS?

I can handle everything except for some of the proposed object literal shorthands (see code at the bottom of this email). Read on.

> Quasi-literals rule, and `` is the right quoting system given the characters left that can be easily typed and that don't ding readability.

Yes, I love them and hope that assignment via ${=x} makes it into ES.next, because that’ll enable us to do all kinds of matching.

> We have <| but it is a bit contentious. No one has topped it, though, and a keyword instead seems to lose on both restricted-production and no-better-word-than-<| grounds.

I like that one, it’s very visual; I find it more descriptive than the keyword "proto".

> Some find -> and => cryptic, but it's hard to say the only alternative is to stick to eight-letter 'function'. ('lambda' is not reserved and can't be used without breaking compatibility; and it's six letters.)
> 
> Some find block-lambdas with their Ruby- (and to a lesser extend Smalltalk-) inspired {||...} bracketing cryptic.

- Pro block-lambdas: A new construct that can be used in places where dynamic |this| (that normal functions are always going to have) would be a burden.

- Pro arrows: little semantic change. With the shorthand for methods in object literals, there is the question whether dynamic |this| is ever needed. But if we need both dynamic and lexical |this|, then the arrows are nice in that they look similar, but are still different.

- Pro ƒ: short, syntactically very similar to current semantics *and* syntax. And as easy to type on a German Mac keyboard as curly braces and square brackets. But I respect the reasoning against it and am in awe that you still have the patience to discuss this kind of issue.

> There are other options, but they all face genreric "too much line noise!" objections.


Programming language syntax is in the same category as politics and religion: There are few simple compromises.

This is me being oblivious to many of the gory details, but if only my taste mattered, then I would do the following:

==== Instead of (example in the proposal) ... ====

var obj = theProtoObj <| {.seal,
    ~konst:= f(), 
    handler: defaultHandler, 
    ~get super set name(v) {throw Error("some message")},
    source() {throw Error("another message")},
    toString() {return "d "+super.toString()}
};

==== ... write the following ====

var obj = theProtoObj <| {.seal,
    @const
    konst: f(),
    
    handler: defaultHandler, 
    
    get name() {
        return super.name;
    },
    set name(v) {
        throw Error("some message");
    },
    
    source() {throw new Error("another message")},
    toString() {return "d "+super.toString()},
];

==== Rationale ====

- Does enumerability ever matter?
- Passing the getter through to the super-class seems like a rare use case. Doing so manually could be optimized by a compiler and while it is a tiny bit verbose, it clearly expresses what is going on. The proposed shorthand is hard to parse for me. Alternative:

    get name() super,
    set name(v) {
        throw Error("some message");
    },


-- 
Dr. Axel Rauschmayer

axel at rauschma.de
twitter.com/rauschma

home: rauschma.de
blog: 2ality.com





More information about the es-discuss mailing list