Skip to content

Support computed properties in class property declarations #1841

Closed

Description

We can emit computed properties class properties, using the following scheme:

class C {
    ["hello"] = 0;
    static ["bye"] = 0;
}

emits as:

var C = (function() {
    var __t1 = "hello";
    function C() {
       this[__t1] = 0;
    }
    C["bye"] = 0;
    return C;
})();

Activity

  1. JsonFreeman commented on Jan 28, 2015

    @JsonFreeman
    ContributorAuthor

    We would only do this for initialized properties. For uninitialized properties, we would have to give an error.

  2. added
    BugA bug in TypeScript
    and removed
    BugA bug in TypeScript
    on Jan 30, 2015
  3. DanielRosenwasser commented on Feb 5, 2015

    @DanielRosenwasser
    Member

    So if you had something like

    var x = 10;
    
    class C {
      [x++] = x;
    }

    I'm assuming that every time the constructor is invoked, the x++ expression gets evaluated.

  4. JsonFreeman commented on Feb 5, 2015

    @JsonFreeman
    ContributorAuthor

    No, that is not the semantics I had in mind. It would get evaluated when the class is evaluated, which happens only once.

  5. DanielRosenwasser commented on Feb 5, 2015

    @DanielRosenwasser
    Member

    Why? We don't cache the initializers anyway.

    TypeScript input:

    var x = 0;
    function f(): number {
        return x++;
    }
    
    class Greeter {
        id: number = f();
        constructor() {
        }
    }

    JavaScript output:

    var x = 0;
    function f() {
        return x++;
    }
    var Greeter = (function () {
        function Greeter() {
            this.id = f();
        }
        return Greeter;
    })();
  6. JsonFreeman commented on Feb 5, 2015

    @JsonFreeman
    ContributorAuthor

    Yeah but we would cache the property name. It feels different from the initializer. But I see what you're saying, we could move the name into the constructor too, unless anyone has objections to that.

  7. DanielRosenwasser commented on Feb 18, 2015

    @DanielRosenwasser
    Member

    As per our design meeting last week, we've decided that we just won't support this because the semantic implications can be counterintuitive.

  8. added
    DeclinedThe issue was declined as something which matches the TypeScript vision
    and removed on Feb 18, 2015
  9. locked and limited conversation to collaborators on Jun 18, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    DeclinedThe issue was declined as something which matches the TypeScript visionSuggestionAn idea for TypeScript

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions