Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Announcing TypeScript 2.0 Beta

blogs.msdn.microsoft.com

Post reply on HN
Print view View original

81–90 of 95 posts

Re: Announcing TypeScript 2.0 Beta

#81

Post by spion »

shados wrote: post #76
ihsw wrote: post #27

Earlier quoted context omitted.

Do you have the same complaints about optional parameters too? let x = (id: number, name?: string) => { return; }; Is it abuse to use interfaces as well? They are not present in vanilla JS. How about React's move away from React.createClass({}) to ES6 classes extending React.Component? Do they abuse classes? Async/await is coming too and it will turn JS on its head, does eschewing callbacks for async functions also c…

You're right, it was never meant to just be annotations+ES6. Though when you talk to someone about TypeScript, they'll argue until they're blue in the face that its just "ES6 with types". I guess you can argue semantics here, but don't be too surprise people will argue back that way.

Uhh, yes it is meant to be just annotations + ES6.

https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi...

The exclamination is a forced cast to another type, just like "x as otherType". So this is still in the same category.

Re: Announcing TypeScript 2.0 Beta

#82

Post by spion »

ihsw wrote: post #27
spriggan3 wrote: post #10

let lowerCased = strs!.map(s => s.toLowerCase()); I'm not a big fan of this, it's really starting to change JS semantics. It's not just type annotations anymore + ES6 . It's starting to look like its own language. Some might like that, I do not. They should be a bit more cautious before introducing these features. What if Ecmascript in the future uses ! as an operator for a totally unrelated purpose ? It's like decor…

Do you have the same complaints about optional parameters too? let x = (id: number, name?: string) => { return; }; Is it abuse to use interfaces as well? They are not present in vanilla JS. How about React's move away from React.createClass({}) to ES6 classes extending React.Component? Do they abuse classes? Async/await is coming too and it will turn JS on its head, does eschewing callbacks for async functions also c…

There is no difference between TypeScript's and Flow's design goals. Flow using the same extension as regular JavaScript is just a dirty marketing trick. Microsoft would be lynched for "embrace-extend-extinguish" if they did the same.

But since its Facebook, its completely fine that they're trying to co-opt standards. No problem at all.

Re: Announcing TypeScript 2.0 Beta

#83

Post by bjconlan »

spriggan3 wrote: post #10

let lowerCased = strs!.map(s => s.toLowerCase()); I'm not a big fan of this, it's really starting to change JS semantics. It's not just type annotations anymore + ES6 . It's starting to look like its own language. Some might like that, I do not. They should be a bit more cautious before introducing these features. What if Ecmascript in the future uses ! as an operator for a totally unrelated purpose ? It's like decor…

I agree, I feel like this is becoming kotlin (not a bad thing) but the syntax is quite a divergence from es5+types less so with es6 but your sentiments are bang on

Re: Announcing TypeScript 2.0 Beta

#84

Post by kilotaras »

extrapickles wrote: post #72
out_of_protocol wrote: post #34

Explain please, why anybody would want both null AND undefined?

It can be useful when calling a function and you want to say "I don't care about parameter X" when null can be an otherwise valid value for that parameter. I've also found it useful when a function needs to indicate it failed but is in a situation where exceptions are not useful. This is code where the consumer of the function can throw its own much more useful exception or can try to recover from the function failin…

For second case most people use options in language that have them.

Re: Announcing TypeScript 2.0 Beta

#85

Post by cakoose »

kagia wrote: post #11
oblio wrote: post #8

Earlier quoted context omitted.

Wouldn't that break third party libraries? You'd also need a compiler flag to enable it only for your own code.

I feel that typescript being only 2.0, should be in a position to break things once in a while. If you pay too much attention to keeping legacy code 'alive' you end up complicating matters with either compiler-flags all over the place or redundant API's i.e win32 api (old+new+newer versions of the same function).

The fact that the flag is global could actually slow down adoption of the new type system.

Let's say I want to use the new type system, but some library I depend on hasn't been updated. If I enable the new type system, I'll get both false positives and negatives when type checking.

If a library writer updated to the new type system, they'd break compatibility with callers that haven't updated. The safest option would be to maintain two almost-identical copies of the library -- one for the old type system and one for the new one.

A better option would be to allow specifying the type system mode at the top of each file (like "use strict"). This allows me to use the new type system even if not all my libraries have updated yet. This also allows libraries writers to use the new type system features without breaking existing users.

Re: Announcing TypeScript 2.0 Beta

#86

Post by Eridrus »

spicyj wrote: post #44
spriggan3 wrote: post #31

Earlier quoted context omitted.

> let x = (id: number, name?: string) => { return; }; hmm, it would make more sense if it was written like that > let x = (id: number, name: string?) => { return; }; But I guess it's more or less ok. But I definitely feel inconfortable with the ! . > How about React's move away from React.createClass({}) to ES6 classes extending React.Component? Do they abuse classes? I don't use React. > Async/await is coming too an…

> I'm not interested in Flow. Curious: Why not?

Is there a reason to use Flow rather than Typescript now?

It seems to have interprocedural type inference, which is really cool, but I'm not sure that's a feature I'd even want in Typescript, since I feel like it would make code less self documenting.

Overall it seems like there is more community support for Typescript than Flow, which is essentially just group inertia, but it makes me not want to switch.

Re: Announcing TypeScript 2.0 Beta

#87

Post by h_r »

johnfn wrote: post #38
spriggan3 wrote: post #10

let lowerCased = strs!.map(s => s.toLowerCase()); I'm not a big fan of this, it's really starting to change JS semantics. It's not just type annotations anymore + ES6 . It's starting to look like its own language. Some might like that, I do not. They should be a bit more cautious before introducing these features. What if Ecmascript in the future uses ! as an operator for a totally unrelated purpose ? It's like decor…

This post is full of misplaced FUD. > It's not just type annotations anymore + ES6 How not? ! is just an inline type coercion. > What if Ecmascript in the future uses ! as an operator for a totally unrelated purpose ? This seems unlikely because ! is already an operator in JS. But really, this argument could be made against any operator TS uses. What if ES introduces : as an operator? Or if they introduce some sort o…

>! is just an inline type coercion.

Are you sure about that? It sounds more like a signal to the compiler to "trust me, I know what I'm doing" and would blow up if you passed undefined anyway. Maybe the author didn't explain it very well. That is, not a type coercion so much as a hint to not bother checking this access.

Re: Announcing TypeScript 2.0 Beta

#89

Post by nippur72 »

tomduncalf wrote: post #65
jsheard wrote: post #12

Earlier quoted context omitted.

In the meantime you can use async with TypeScripts ES6 emitter, which transforms async into generators, then run the output through Babel to transform the generators into plain old ES3/ES5. It's messy but it works.

If anyone is interested in this setup, I wrote a blog post recently about setting up Typescript with Webpack and React which describes how to set it up so that the Typescript output passes through Babel: http://blog.tomduncalf.com/posts/setting-up-typescript-and-r...

thanks it's very useful, as I now I doubt async/await will ever land in TS.

Re: Announcing TypeScript 2.0 Beta

#90

Post by johnfn »

h_r wrote: post #87
johnfn wrote: post #38

Earlier quoted context omitted.

This post is full of misplaced FUD. > It's not just type annotations anymore + ES6 How not? ! is just an inline type coercion. > What if Ecmascript in the future uses ! as an operator for a totally unrelated purpose ? This seems unlikely because ! is already an operator in JS. But really, this argument could be made against any operator TS uses. What if ES introduces : as an operator? Or if they introduce some sort o…

>! is just an inline type coercion. Are you sure about that? It sounds more like a signal to the compiler to "trust me, I know what I'm doing" and would blow up if you passed undefined anyway. Maybe the author didn't explain it very well. That is, not a type coercion so much as a hint to not bother checking this access.

When would code with ! ever compile differently than code without ! ?
Post reply on HN