Announcing TypeScript 1.6
blogs.msdn.com
blogs.msdn.com
Seriously, how cool is that? (Even though admittedly there are soundness issues with TypeScript, its still pretty damn amazing)
Also, TypeScript has a fairly strong transpilation engine and can be a one-stop shop for most of your transpilation needs (contrasting to also needing something Babel or Traceur in your build and/or runtime stack, for instance, because you can just transpile ES6-like TypeScript directly to ES5).
If I have Printable and Drawable interfaces, which each describe a set of behaviors, then I would expect the "intersection" of Printable and Drawable to be the intersection of those sets of behaviors — which, here, is likely the empty set.
Is there another way of understanding types that makes the word "intersection" make more sense here? Or is it just to say that "where union types say OR, intersection types say AND"?
---
...ya know what? By typing it out, I think I get it now.
The set that we're talking about isn't the set of Printable's behaviors; it's the set of things that implement Printable. `Printable & Drawable` is the intersection of the set of types that implement Printable with the set of types that implement Drawable. Got it. Thanks for rubber-ducking for me, HN!
You're not taking the intersection of the interfaces, but of the sets of objects that implement them.
See the response about C#.
If you think of Set X consisting of all the objects that could possibly be built as Class X and Set Y as all the objects that could possibly be built as Class Y, then the union of those sets is all of the Class X derived objects and all of the Class Y derived objects, whereas the intersection of those sets are whatever objects manage to implement or derive from both Class X and Class Y.
Really looking forward to async/await support[0]. This will simplify vast swaths of async code trapped in callback hell or promise purgatory.
It appears async support has been pushed out until TypeScript 2.0.
The surprise in TypeScript 1.6 is that experimental support for async/await is actually included, with the caveats that you have to explicitly opt in to the experimental feature with a compiler flag and that it only works when outputting ES6 code (it fails for ES3 and ES5). Some details are at the bottom of the issue 1664.
Also, I think the new typing capabilities are hugely sexy if you've ever had to write .d.ts files for wild JS. Generic type aliases and intersection types will solve a lot of things that were much harder to do in definition files previously.
Also, the support for expressions in class extends clauses makes it a lot easier to use the nicer class syntax when operating with JS libraries that use a custom object factory. (Given the long history of JS OO, there are a lot of weird custom object factories out there in wild JS code.) This is also good catchup with ES6 class syntax; it's always sexy when TS works to keep its "pure superset" goals.
JSX support is a big feature, albeit controversial and not for everyone. Notice Rob Eisenberg's first comment on the blog:
"I do have one concern with this release. Back in the day, Anders was extremely adamant about not including XML in C#. At the time, XML was extremely popular, but today it is much less so. It was a wise decision. Today, I see a release that ties TypeScript to JSX, which seems to fly in the face of the previous language design principle. But furthermore, it is a long held principle that one should not embed JavaScript in HTML. So, why are we so quick to embed HTML in JavaScript? JSX has always seemed like a phenomenally bad idea and one that is certain to be short lived. Can you elaborate on the nature of the JSX integration? I'd like to know that it's not going to affect TS in the long-term. I'd also like to know what type of compiler output it produces. Does it produce React code? or does it produce some sort of string concatenation expression in the end? Did the TS compiler just get tied to the React library's implementation details?"
But I admit that being able to read type signatures in the source code makes understanding a code base way easier, it's just that people tend to be more verbose going full OOP , even when it is not necessary. But kudos for Microsoft, if only they would have accepted ES4 8 years ago, TS would not have been needed.
And by the way Microsoft, why not make Jscript.net cool again ?
If I was writing TypeScript, I'd be using functions and simple objects.
Even "Enterprise JavaScript" is a step up from the hodge podge "no paradigm" JS that has classically littered the web. It's nice seeing actual architecture and planning in JS codebases these days, with and without the big rigid frameworks. Sure, a lot of it is more verbose than it needs to be and over-architecture is an easy over correction to make, but typically I'll take over-architecture over no-architecture any day of the week. (Even if most of the joy I get from over-architecture is taking sledge hammers to it and reducing it down to a tighter core. Net negative lines of code refactors are a wonderful thing.)
I tried to use it the other day with node.js but couldn't find a type file for the popular simple-oauth2 package.
However it should be fairly easy to write a .d.ts file for it. You don't even have to cover the entire library - its enough to specify the types of the parts you use.
and TSD to copy into your directory from DT (it's like a package manager for definitions). Not ideal but that's the practice. Doesn't cover your simple-oauth2 example though, but its not that bad adding the individual methods you need on demand (easier if you have the definatelyTyped examples to follow).
For downloading plugin for VS 2015 available at:http://www.microsoft.com/en-us/download/details.aspx?id=4859...
and VS 2013 available at: http://www.microsoft.com/en-us/download/details.aspx?id=4873...