Incorrect/overly strong `this` inference for POJOs

[chancancode]

TypeScript Version:

nightly (1.9.0-dev.20160419)

Code

Ember.Object.extend({
  init() {
    this._super();
//  ^~~~ error TS2339: Property '_super' does not exist on type '{ init(): void; }'.
    ...
  }
});

Expected behavior:

this should be inferred as any

Actual behavior:

this is inferred to be { init(): void; }

---

This changed somewhere between typescript@1.9.0-dev.20160319 and typescript@1.9.0-dev.20160419. I believe it is unsafe to assume anything about the this on the "methods" on a POJO, as there are several common patterns in JavaScript that breaks this assumption (using POJOs as an "options" or "extensions" dictionary).

[wycats]

I'd like to add that TC39 had the opportunity to make the desugaring from init() {} something more involved than init: function() {}. In particular, we were considering making "methods" on POJOs non-enumerable. I argued strongly against that course and we chose to stick with a simple desugaring.

The problem (in that context) that I was worried about, is that existing code expects to take a POJO, enumerate over its properties, and do something with that enumeration. The class pattern is the most common example, but options bags that can contain arbitrary functions is common as well.

I was worried that if refactoring from foo: function() {} to foo() {} in an object literal quite often didn't behave as expected, people would become resistant to the refactoring. In contrast, the complete refactoring for most POJOs containing "real methods" is refactoring to classes, which are a sufficiently different construct to justify the change in behavior (that refactoring is already sufficiently non-mechanical).

A similar situation is happening here in my opinion. Because there are some use-cases where inferring this from a POJO is convenient, we are creating an upwards refactoring problem from foo: function() {} to foo() {}. In practice, this will cause resistance to moving to the more concise form, which is something we expressly chose to avoid in TC39 (for good reason).

The meaning of "method in a POJO" is simply too ambiguous to try to guess that the user probably meant "this object is a singleton with methods", and that approach creates too much friction to using concise methods in the large to justify the cognitive overhead, in my opinion.

[RyanCavanaugh]

On the other hand, we've gotten the request to type this inside object literal functions about eleventy million times already. 😕

[wycats]

@RyanCavanaugh Are you sure that the eleventy million times are all cases where the object literal is the correct this, vs. cases like .extend(POJO) or defineClass(POJO) which wants a different behavior?

In my JavaScript experience, the set of cases where this inside an object literal is actually referring to the object itself (as opposed to a transplant object or with a this provided by an API like jQuery.ajax) is relatively small.

[mhegazy]

extend could define a contextual type for this to be Ember.CoreObject for instance, would that be desired in your scenario?

[wycats]

@mhegazy what we want is extend<T>(extension: T): this & T, where the resulting value is a valid superclass (we're willing to be explicit about that if necessary).

[wycats]

Actually that isn't quite right: this is the superclass and T augments the instance side, and we're returning a typeof that augmented type.

[wycats]

But more generally, I don't think this change in behavior is what people have in mind much of the time when they ask for this to be typed. It really does need to be specified by the code that takes the POJO, and not assumed to be the singleton POJO itself.

Or even more generally, it should be the job of jQuery, Ember.Object, Backbone.Model, React.createClass, etc to provide the this binding, not TypeScript.

[mhegazy]

the counter example is:

var x = {
    foo() { .. },
    bar() {  this.|  /* why no foo here? */ }
};

[wycats]

That may be a theoretical counterexample but how often does it happen in practice relative to the React.createClass and jQuery.ajax patterns?

At least for me, cases where I'm writing a POJO with methods that I intend to use as-is is in the minority relative to cases where this is provided by the callee.

This change means that people writing Backbone.Model.extend, React.createClass or Ember.Object.extend (as well as jQuery.ajax, new Benchmark(options), etc.) will not be able to use concise syntax, or they will have to say this as any a lot. I don't think that tradeoff is worth it.

It will also produce this WAT that is similar to yours:

let options = {
  url: "microsoft.com"
};
Object.assign(options, {
  invoke() { /* why doesn't this.url work? */ }
});

[RyanCavanaugh]

Right on cue? http://stackoverflow.com/questions/36730275/create-object-with-part-of-interface-typescript

[DanielRosenwasser]

or they will have to say this as any a lot

Well you'll be able to specify the type of this in each method, so you'll only have to do it once at the top of your method. Not necessarily the best if it wasn't your intention to get an automatic this type, but certainly not the worst either.

[wycats]

@DanielRosenwasser I don't know what criteria or rationale you are using to discuss this topic, but it would be helpful for me to understand:

1. Of the complaints that you have received, what concrete cases involving POJOs and this would be satisfied by this change? How many of them involve partial interfaces, where people would expect this.| to complete with fields and methods from the super-interface?
2. Of the complaints that you have received, how many cases look like partial interfaces, and how many look like options bags whose this is supplied by the caller?

It may well be that I'm in a bubble, and (2) is much less common in the real world than (1), but I'd really appreciate some insight here.