Member variables (getters/setters) are too slow.

[vojtajina]

This is a discussion.

Currently we generate getters/setters for member variables (class fields), so that we can do the runtime type check. This has two issues:

• it is very slow (esp. on Safari),
• makes the code hard to debug.

What can we do?

• completely disable runtime type checking for member variables,
• only generate them when runtime type asserts are enabled,
• add another flag such as memberVariablesTypeAssertions,
• something else?

What do you think? @arv @vicb

[arv]

Are runtime asserts slower on accessors than methods, or is it accessors that are slower in general?

[vojtajina]

Accessors are slow, even without asserts.

[arv]

Since accessors and instance properties have different semantics I think we would need to do what TS does and make these instance properties in all cases. However, that makes the runtime type asserts unreliable.

[vicb]

@vojtajina

• I think we only need getters/setters when type assertions are enabled. Then there would be no perf problem in production where assertions are disabled,
• when getters/setters are generated, debugging is hard because "propName" get renamed to "$0". One way to solve this would be to use "$0propName" or "propName$__0"

also see #1530

[vicb]

TS does not generate accessors because there is no runtime type check:

class Base {
    a: number = 0;
    consructor() {      
    }
}

class Child extends Base{
    b: string = 'foo';
    constructor() {
        super();
        this.a = this.b;
    }       
}

console.log(JSON.stringify(new Child()));

TS would detect an error on this.a = this.b. You can still execute the generated JS and get {"a":"foo","b":"foo"}.

With the current traceur JSON.stringify would return mangled property names, ie {"$__0":"foo","$__1":"foo"}.

I can not think of a way of adding type assertions on class fields and still have the correct output for JSON.stringify() - adding assertions on all the field accesses in a class would not work for inherited fields.

If we decide that the output of JSON.stringify() should keep the original names (which is a sensible choice) then we should stop generating accessors. It also means that the field types won't be used any more. Class field types can be used later when/if traceur implements compile time type checking (as TS does). They will also be used in Angular when the target language is Dart.

[vojtajina]

The debugging issue could be solved by naming the properties, like @vicb suggested. There is another problem: JSON.stringify will produce different output with getters.

I see three options:

• disable getters/setters (and thus runtime check for fields; this means we are inconsitent when generating runtime checks and when not - anywhere user annotates the type, we generate the check, except for the class fields)
• break JSON.stringify
• put it under special flag memberVariableTypeAssertions (== we don't know and put the burden of this decision on the user who can decide between the previous two cases).