Implement Getter and Setters for ES3 via compiler

[shmuelie]

The power of properties is great and sadly they don't exist in ES3. We do though have a compiler that could convert the property and all it's calls to get and set calls.

For naming I think simply appending _get or _set to the property's name would work. Then it's just a case of looking for all reads, replacing them with calls to property_get() and all sets with calls to property_set(value).

We have the calling information since we can do refactoring, so I'd think changing the usages to function calls could be done.

Thoughts?

[RyanCavanaugh]

Consider code like this:

interface Point {
  x: number;
  y: number;
}

function print(pt: Point) {
  console.log('x = ' + pt.x + ', y = ' + pt.y);
}

var a = { x: 3, y: 5 };
var b = {
  get x() { return 1; },
  get y() { return 2; }
};

var c = Math.random() > 0.5 ? a : b;
print(c);

There's no sensible way to rewrite this into getter/setter calls

[shmuelie]

Why not

function print(pt: Point) {
    console.log('x = ' + (pt.x || pt.x_get()) + ', y = ' + (pt.y || pt.get_y()));
}

?

[RyanCavanaugh]

You're proposing that every single property access in a program be rewritten to something like that?

[shmuelie]

Not every, only cases like the above where we don't know

[RyanCavanaugh]

The problem is that print may have been compiled in a separate compilation from b, so the compiler has no way of knowing that the function won't be invoked with some object that uses getters. So "the cases where we don't know" is actually equivalent to "every"

[shmuelie]

Sadly yes, short of doing that for every property access (which I agree would be a bit much) my idea is dead.

[birbilis]

Compiled objects could have some annotation/metadata to declare their target Javascript (during compilation). So when you imported precompiled blackbox .ts code and compiled against it some code of yours using them the compiler would/should be able to know what semantics to use to talk to them, depending on their target and your target.

Also, if you specified ES3 target for example and you were using third-party precompiled modules compiled for ES5 it would be able to warn you against it.

Now if you mixed and matched several precompiled .ts of different targets at runtime it would be a problem, but could resolve that by having option to emit file-extensions of the style .es3.js and .es5.js that users could have optionally to be specific about target and avoid such mixups if they do such practice.

In fact instead of keeping metadata of target in the javascript in some special comment (if fearing of poluting it) could keep in the filename. Wouldn't mind such a comment at top of file though to know with which target option (or other compiler params like optimization or whatever may be there) the .js I'm looking at was generated. Of course when merging .js files into one it would be an issue.

However, I think I'm derailing here - if people want to use precompiled .ts as a .js blackbox, then they should have a typings file with it too that could have itself the target annotation (could even opt to have it per class when doing merging of multiple such .js files into one). That would be helpful metadata when wrapping other libraries in .ts typings too (and even automated tool could parse a .js and decide if it should be marked with ES3 or higher (minimum) javascript engine requirement)