4 ms·
The value depends on how you call the function at runtime which requires much deeper code analysis than something like syntax highlighting.
by _sdegutis 9y ago
The value depends on how you call the function at runtime which requires much deeper code analysis than something like syntax highlighting.
- brlewis 9y agoI'm interested as to whether they did deep code analysis or just added the (not strictly correct, but not terrible) assumption that `this` refers to an instance of the class you're defining. Unfortunately this article is light on links to original source material.
- mattbierner 9y agoNo we don’t do that. In TypeScript code ‘this’ is typed, and we can infer the type of this for classes and ES5 classes in JS. However we don’t analyze calls to ‘.call’ or ‘.apply’ to infer the type of ‘this’ in a given function.
- vbezhenar 9y agoI think that the best editing experience would be editor combined with debugger. JavaScript is a dynamic language, a lot of autocompletes before run is just guesses. But if you're running program and stopped it at that line, you know all available objects and their properties, so autocomplete would be perfect. It would require a bit different development style, but it might worth it.
- DougBTX 9y agoChrome's development tools actually allow saving changes to the JS files AFAIK, or going the other way around, it is possible to debug JS running in the browser from VS Code using the devtools-protocol: https://github.com/ChromeDevTools/devtools-protocol https://github.com/ChromeDevTools/devtools-protocol
- chatmasta 9y agoProblem is enumerating all the possible code paths that could break at the current line.
- seanmcdirmid 9y agoIf you just want a heuristic, having one value is really useful. Polymorphism is rather rarely used anyways.
- vbezhenar 9y agoThat's developer problem. I'll provide input values for needed use-case myself (for example with unit test or just manually) and IDE should stop at given line and provide autocomplete. I don't think that there's implementation difficulty, it's just a bit different style of coding, but it should work very well with test driven development.
- Vinnl 9y agoSo let's say I have this function: function example() { console.log(this.v); }; Which I call twice: example.apply({ v: 'One' }) example.apply({ v: 'Two' }) How can code analysis tell you the value of `this`?
- aljarry 9y agoIt's only working inside of EC6 classes.
- Vinnl 9y agoWell, how about this then: class ExampleClass { example() { console.log(this.v); } } Called as such: const e = new ExampleClass(); e.example.apply({ v: 'One' }); e.example.apply({ v: 'Two' });
- aljarry 9y agoI don't see how could it support properties added at runtime. I'd wager it supports only the properties defined inside of the class.
- DougBTX 9y agoWith the --noImplicitThis flag set, then the first line will fail to compile, with an error: 'this' implicitly has type 'any' because it does not have a type annotation. That error can be fixed by specifying an explicit type annotation for this: function example(this: { v: string }) { console.log(this.v); }; However, the type checking for apply is still too weak to produce any useful errors, as even with the above type annotation, this will still compile: example.apply({ b: 3 }) The type of apply is currently: Function.apply(this: Function, thisArg: any, argArray?: any): any It accepts basically any arguments. In future perhaps they will make this stricter, more discussion here: https://github.com/Microsoft/TypeScript/issues/212 https://github.com/Microsoft/TypeScript/issues/212
- jfaat 9y ago