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

Announcing TypeScript 1.7

blogs.msdn.com

Post reply on HN
Print view View original

81–90 of 93 posts

Re: Announcing TypeScript 1.7

#81

Post by drinchev »

MasterScrat wrote: post #68
aozgaa wrote: post #50

Earlier quoted context omitted.

I can't speak to atom, but have you considered Visual Studio Code? That and VS2015 are tightly integrated with the TypeScript compiler and language service (provides autocomplete, type hinting, go-to definition, etc.). For sublime, there is a plugin actively developed by Microsoft [1]. For vim, the plugin YouCompleteMe provide autocomplete [2]. Also, I haven't tried it, but there's an Emacs-mode, apparently [3]. Ther…

WebStorm (IntelliJ) support is really good as well.

I'm not sure how this support will be added though. So far the last WebStorm ( which arrived a month ago ) supports 1.6, but definitely not as good as let's say visual code.

Example for that is lack of per module definition files .d.ts and package.json typing a property.

I'm fairly In a mood to switch to visual code or Atom, since I write exclusively typescript nowadays.

Re: Announcing TypeScript 1.7

#82

Post by mercer »

Keats wrote: post #72
haberman wrote: post #26

Earlier quoted context omitted.

How is this different from using Facebook Flow? I have been using Flow on a JavaScript project, along with Babel for ES6, and enjoying the experience quite a lot.

We compared Flow and Typescript for our projects, you can see the articles https://blog.wearewizards.io/flow-and-typescript-part-1-flow and https://blog.wearewizards.io/flow-and-typescript-part-2-type... TL;DR: Flow inference is super nice but community and tooling is lacking compared to TypeScript imo so we ended up using TS

Thank you for the links. I've been looking into both and also ended up with TypeScript, but for no particular good reason. These articles are helpful!

Re: Announcing TypeScript 1.7

#83

Post by spankalee »

spion wrote: post #59
mythz wrote: post #41

Earlier quoted context omitted.

> That assumes setupBase(), etc are either void-returning or return the this-instance (newModel). This is Incorrect, it doesn't assume anything. Dart's method cascades just returns the receiver, it doesn't matter what the method returns, it's value is ignored and receiver is returned instead. http://news.dartlang.org/2012/02/method-cascades-in-dart-pos... Since the return value is ignored, it's only useful for method…

It assumes you have a stateful, side-effectful API when you could instead have an API that returns new immutable objects of the same type

In that case instead of cascades you just use regular invocation.

Re: Announcing TypeScript 1.7

#84

Post by Arnavion »

mythz wrote: post #41
Arnavion wrote: post #4

Earlier quoted context omitted.

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(); That is, it ignores the result of the method and runs the remainin…

> That assumes setupBase(), etc are either void-returning or return the this-instance (newModel). This is Incorrect, it doesn't assume anything. Dart's method cascades just returns the receiver, it doesn't matter what the method returns, it's value is ignored and receiver is returned instead. http://news.dartlang.org/2012/02/method-cascades-in-dart-pos... Since the return value is ignored, it's only useful for method…

>This is Incorrect, it doesn't assume anything. Dart's method cascades just returns the receiver, it doesn't matter what the method returns, it's value is ignored and receiver is returned instead.

... which would only be useful if the method was void-returning or returned the this-instance, i.e., it didn't return a new instance and left the LHS unmodified.

Re: Announcing TypeScript 1.7

#85

Post by Arnavion »

sjrd wrote: post #73
Arnavion wrote: post #4

Earlier quoted context omitted.

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(); That is, it ignores the result of the method and runs the remainin…

> It won't work if each method returns a new instance, such as methods of immutable collections. TS' this type does not allow that either. You have to return `this`, and nothing else. This can be explained by inheritance. If you extend a class with a method returning a `this` type, but not returning `this`, somehow you should be forced to override that method. But you probably don't want that. Also, the `this` type i…

D'oh! You're right of course.

Re: Announcing TypeScript 1.7

#86

Post by [deleted] »

Arnavion wrote: post #84
mythz wrote: post #41

Earlier quoted context omitted.

> That assumes setupBase(), etc are either void-returning or return the this-instance (newModel). This is Incorrect, it doesn't assume anything. Dart's method cascades just returns the receiver, it doesn't matter what the method returns, it's value is ignored and receiver is returned instead. http://news.dartlang.org/2012/02/method-cascades-in-dart-pos... Since the return value is ignored, it's only useful for method…

>This is Incorrect, it doesn't assume anything. Dart's method cascades just returns the receiver, it doesn't matter what the method returns, it's value is ignored and receiver is returned instead. ... which would only be useful if the method was void-returning or returned the this-instance, i.e., it didn't return a new instance and left the LHS unmodified.

[deleted]

Re: Announcing TypeScript 1.7

#87

Post by [deleted] »

Arnavion wrote: post #84
mythz wrote: post #41

Earlier quoted context omitted.

> That assumes setupBase(), etc are either void-returning or return the this-instance (newModel). This is Incorrect, it doesn't assume anything. Dart's method cascades just returns the receiver, it doesn't matter what the method returns, it's value is ignored and receiver is returned instead. http://news.dartlang.org/2012/02/method-cascades-in-dart-pos... Since the return value is ignored, it's only useful for method…

>This is Incorrect, it doesn't assume anything. Dart's method cascades just returns the receiver, it doesn't matter what the method returns, it's value is ignored and receiver is returned instead. ... which would only be useful if the method was void-returning or returned the this-instance, i.e., it didn't return a new instance and left the LHS unmodified.

[deleted]

Re: Announcing TypeScript 1.7

#88

Post by mythz »

Arnavion wrote: post #84
mythz wrote: post #41

Earlier quoted context omitted.

> That assumes setupBase(), etc are either void-returning or return the this-instance (newModel). This is Incorrect, it doesn't assume anything. Dart's method cascades just returns the receiver, it doesn't matter what the method returns, it's value is ignored and receiver is returned instead. http://news.dartlang.org/2012/02/method-cascades-in-dart-pos... Since the return value is ignored, it's only useful for method…

>This is Incorrect, it doesn't assume anything. Dart's method cascades just returns the receiver, it doesn't matter what the method returns, it's value is ignored and receiver is returned instead. ... which would only be useful if the method was void-returning or returned the this-instance, i.e., it didn't return a new instance and left the LHS unmodified.

> which would only be useful if the method was void-returning or returned the this-instance

Simply untrue, there are plenty of times methods have side-effects that return something other than void or itself, e.g:

  - Incrementing a value and returning the current value
  - Inserting or Updating rows and returning the number of rows affected
  - Setting an entry and returning whether there was an existing entry or not

Re: Announcing TypeScript 1.7

#89

Post by astrafoo »

stewbrew wrote: post #58

I'd like to see a thorough comparison of typescript, haxe, scala.js, and also gopherjs. Which (statically typed) language/compiler provides the best experience for developers who want to develop "native" programs (I include here jvm and node) and javascript for the web with one language using the same libraries?

http://www.scala-js.org/ has a nice comparison between JavaScript, ECMAScript 6, TypeScript and Scala.

I'm not sure there is much substance to develop "native" programs in TypeScript/Haxe/... they don't have an ecosystem outside the web, while Scala has tons of mature libraries, access to all the Java stuff ever written, and runs on the best, mature, well-supported, high-performance runtime you can get.

Re: Announcing TypeScript 1.7

#90

Post by freditup »

DCoder wrote: post #64
freditup wrote: post #22

Earlier quoted context omitted.

Yes, you can: https://github.com/Microsoft/TypeScript/wiki/Using-the-Langu...

There are some subtle behavioural differences between the Language Service and the regular compiler, for example: https://github.com/Microsoft/TypeScript/issues/5243

Good clarification. Perhaps the compiler API is the better choice here? I'm not fully aware of the differences / divisions between the two. https://github.com/Microsoft/TypeScript/wiki/Using-the-Compi...
Post reply on HN