Announcing TypeScript 1.7
blogs.msdn.com
Announcing TypeScript 1.7
1–10 of 93 posts
Re: Announcing TypeScript 1.7
#2Awesome work by the TypeScript team - they have been moving very fast to improve TypeScript over the course of this year, and I am impressed by the amount of effort Microsoft has poured into this. Using TS now is pretty nice, and has already paid dividends at work in catching some subtle bugs
Re: Announcing TypeScript 1.7
#3Polymorphic this Typing seems like a major change with many possible corner cases. I think Dart .. operator is a better solution
newModel.setupBase().setupAdvanced();
newModel..setupBase()..setupAdvanced();Re: Announcing TypeScript 1.7
#4Polymorphic this Typing seems like a major change with many possible corner cases. I think Dart .. operator is a better solution newModel.setupBase().setupAdvanced(); becomes newModel..setupBase()..setupAdvanced();
That assumes setupBase(), etc are either void-returning or return the this-instance (newModel). It won't work if each method returns a new instance, such as methods of immutable collections.
Edit: Since this is hard to google for, this is called the "cascade operator". The given example is equivalent to:
newModel.setupBase(); newModel.setupAdvanced();
Re: Announcing TypeScript 1.7
#5To me, this appears to be the way to go. Javascript + Typescript. Rather than deciding on weak (dynamic) typing vs strong typing, you pick both - incremental typing, as allowed by Typescript.
Want to bang up a quick solution, as in MVP? Use bare-bones Javascript, it is all valid Typescript. So you get dynamic typing. And if you do not care about strong typing, you can just stop right there.
But if you, some day, for whatever reason, decide that you feel like strong typing: good - you do not need to rewrite your app in a different language - just go back to your code and add some type info, here and there, at your leisure. As you do that, you get all the benefits of static typing, ie compiler showing you obvious type-related errors, correct keyword-completion, exact refactorings, etc etc.
Looks like the best of both worlds.
Re: Announcing TypeScript 1.7
#6> This type can be used in classes and interfaces to represent some type that is a subtype of the containing type (rather than the containing type itself)
Could that not be achieved by having covariant return types instead?
Re: Announcing TypeScript 1.7
#7To me, this appears to be the way to go. Javascript + Typescript. Rather than deciding on weak (dynamic) typing vs strong typing, you pick both - incremental typing, as allowed by Typescript. Want to bang up a quick solution, as in MVP? Use bare-bones Javascript, it is all valid Typescript. So you get dynamic typing. And if you do not care about strong typing, you can just stop right there. But if you, some day, for…
Can TypeScript do runtime enforcement at the boundaries between typed and untyped code, though?
Re: Announcing TypeScript 1.7
#8To me, this appears to be the way to go. Javascript + Typescript. Rather than deciding on weak (dynamic) typing vs strong typing, you pick both - incremental typing, as allowed by Typescript. Want to bang up a quick solution, as in MVP? Use bare-bones Javascript, it is all valid Typescript. So you get dynamic typing. And if you do not care about strong typing, you can just stop right there. But if you, some day, for…
Can TypeScript do runtime enforcement at the boundaries between typed and untyped code, though?
No, and you wouldn't want the overhead. You can turn on warnings though if you want to make sure all your code is typed on compile. After compiling all type definitions are stripped and you're left with plain javascript.
Re: Announcing TypeScript 1.7
#9> This type can be used in classes and interfaces to represent some type that is a subtype of the containing type (rather than the containing type itself) Could that not be achieved by having covariant return types instead?
Sure, but that would require every subtype to override every method of the base type with a narrower return type, and do nothing except delegate to the base type in the body. It would be tedious boilerplate.
Since the base type's implementation already returns `this`, it makes sense to be able to annotate the method as returning `this` and get the benefit automatically.
Re: Announcing TypeScript 1.7
#10> This type can be used in classes and interfaces to represent some type that is a subtype of the containing type (rather than the containing type itself) Could that not be achieved by having covariant return types instead?
Sure, but that would require every subtype to override every method of the base type with a narrower return type, and do nothing except delegate to the base type in the body. It would be tedious boilerplate. Since the base type's implementation already returns `this`, it makes sense to be able to annotate the method as returning `this` and get the benefit automatically.
[deleted]