Open sandersn opened 8 years ago
This is interesting. The problem I see with introduce an implicit this
on interface types is that currently there is a lot of valuable flexibility in terms of how a member is implemented.
Given the declaration
interface I {
m(x: number): void;
}
declare function f(o: I);
It can be implemented via a property or a method which is very handy if I am implementing it with an object literal, and want to retain the lexical this
. I can implement I
with a property m
this.value = 42;
f({
m: (x) => console.log(this.value)
});
From #23749
I understand why TypeScript can't ditch this horrible behavior and evaluate the code sanely for reasons of backwards compatibility when changing JS file extensions to .TS, but as this is a common type-safety issue, I feel like TS should take measures to mitigate the issue.
TypeScript should be able to catch the unsafe usage of this in the example above (it fails the assertions).
Additionally, when typing this.
, the suggestions generated are for values based on the current scope instead of being any or something else, leading one to believe the code is correct.
Suggestions:
this.xxx
is assigned to an object of a different type from the type of this
in the current scope?self
, the value of which binds to the current value of this
that can be used instead.Briefly, if every interface has a this type, then every interface will be generic, even in non-OO code. This causes the compiler to generate about double the number of types internally, which is slower and uses more memory than today.
Wouldn't it be possible to use the concrete type of the class/interface, i.e. this: Foo
instead of this: this
?
The more I think about it, the more I feel self
is the answer here?
Duplicate of #7968 or vice versa?
This means that only very careful people will benefit from assignability checking (and therefore argument checking at call sites). (Due to contextual typing, code that uses a this-typed library will get improved body checking a lot of the time.)
Specifically, assignability checking only happens when
this
is explicitly declared by both sides.Instead, class methods should implicitly have
this: this
unless declared otherwise.Given the declarations:
Expected behavior:
Actual behavior:
Comments
The "this parameter" feature was designed this way to balance four concerns:
this
.As you can see, (4) took the biggest hit by requiring annotation on both the source and target of the assignment.
Backward compatibility
The problem with unannotated code is that we can't tell whether a function is intended to be called with or without
this
.Functions
--noImplicitThis
helps address this problem by forcing annotation of this parameters for functions.TODO: Work through some examples.
Methods
Actually, for methods, we do have a pretty good idea that a method is not supposed to be removed from its class. Even if the class implements an interface, we the class methods should still be able to refer to class-private implementation details.
TODO: Work through some examples.
Interface consistency
The problem is that interfaces are frequently used to interact with objects instead of the class type itself. But interfaces are used in lots of other contexts as well. That means we can't infer intent with an interface, but if we don't add
this: this
to interface methods, we're left with a bad assignment problem:"Assignment escape hatches" like this exist throughout TypeScript, but adding more is not a good thing.
Efficiency
Briefly, if every interface has a
this
type, then every interface will be generic, even in non-OO code. This causes the compiler to generate about double the number of types internally, which is slower and uses more memory than today.