Live data from Hacker News

TypeScript 2.4

blogs.msdn.microsoft.com

31–40 of 52 posts

Re: TypeScript 2.4

#31
post #25

> Strict contravariance for callback parameters ?TypeScript has always compared parameters in a bivariant way. There are a number of reasons for this, and for the most part it didn’t appear to be a major issue until we heard more from users about the adverse effects it had with Promises and Observables… > TypeScript 2.4 now tightens up how it checks two function types by enforcing the correct directionality on callba…

I would love for an ELI5 explanation of covariance/contravariance, but I've never seen one. I get it now, but only after reading and rereading explanations very carefully.

So, then how would you explain it to a five year old?

Re: TypeScript 2.4

#32
post #25

> Strict contravariance for callback parameters ?TypeScript has always compared parameters in a bivariant way. There are a number of reasons for this, and for the most part it didn’t appear to be a major issue until we heard more from users about the adverse effects it had with Promises and Observables… > TypeScript 2.4 now tightens up how it checks two function types by enforcing the correct directionality on callba…

I would love for an ELI5 explanation of covariance/contravariance, but I've never seen one. I get it now, but only after reading and rereading explanations very carefully.

Perfect, would you be willing to write one?

Re: TypeScript 2.4

#33

Dart with dynamic js compiler (DDC) is getting better too: http://news.dartlang.org/2017/06/a-stronger-dart-for-everyon...

The problem with Dart, is that it is a pain to interact with JavaScript libraries, let's see if Dart 2 makes it better.

Re: TypeScript 2.4

#34

Earlier quoted context omitted.

I would love for an ELI5 explanation of covariance/contravariance, but I've never seen one. I get it now, but only after reading and rereading explanations very carefully.

So, then how would you explain it to a five year old?

Imagine a pipe that only fits dogs. The pipe has two ends. One side has person A pushing dogs into the pipe - the source. The other side has person B pulling dogs out of the pipe - the sink.

The source can push anything into the pipe that is a dog or more specialized than a dog, ie they can push in specific dog breeds like only terriers. So the source can treat the "Pipe of Dog" as a "Pipe of Terrier". It's okay because they're dogs and the pipe accepts dogs. The source cannot push in any animal that isn't a dog.

When the sink pulls something out of the pipe, they can expect to receive anything that's a dog or less specialized than a dog, eg they can expect that everything they receive will be an animal. So the sink can treat the "Pipe of Dog" as a "Pipe of Animal". The sink can expect not to receive anything that isn't an animal. The sink can't expect that they'll only receive terriers, since the source may decide to push bulldogs instead.

The source end of the pipe is contravariant on Dog. The sink end of the pipe is covariant on Dog.

Edit: To bridge this with programming: A function is a pipe. The input of the function is the source. The output of the function is the sink. A function that accepts a Dog could be given a Terrier, and a function that returns a Dog can be considered to return an Animal.

Data structures are equivalent to functions in this respect. A data structure that produces instances of Dog is the same as a function that produces a Dog - IEnumerable in C# is also an IEnumerable, Promise in JavaScript is also a Promise. A data structure that both accepts and returns instances of Dog is invariant on Dog - List in C# can't be List, Array in JavaScript can't be Array, because that would let someone push Cats into them.

Edit 2: By the same reasoning, a callback parameter flips the input-output-variance association for every level of nesting. For a first-level callback, the inputs to the callback are produced by the function, so the input of the callback is equivalent to an output of the function, and the output of the callback is equivalent to an input of the function. Eg consider a JS function `function foo(x: (y: A) => B): C { }` This is covariant on A, contravariant on B, covariant on C.

Re: TypeScript 2.4

#35
post #25

> Strict contravariance for callback parameters ?TypeScript has always compared parameters in a bivariant way. There are a number of reasons for this, and for the most part it didn’t appear to be a major issue until we heard more from users about the adverse effects it had with Promises and Observables… > TypeScript 2.4 now tightens up how it checks two function types by enforcing the correct directionality on callba…

I would love for an ELI5 explanation of covariance/contravariance, but I've never seen one. I get it now, but only after reading and rereading explanations very carefully.

I recall Eric Lippert's article series on the topic to be well written and well explained.

It starts here:

https://blogs.msdn.microsoft.com/ericlippert/2007/10/16/cova...

You can follow along further through the tag:

https://blogs.msdn.microsoft.com/ericlippert/tag/covariance-...

Re: TypeScript 2.4

#36

Earlier quoted context omitted.

So, then how would you explain it to a five year old?

Imagine a pipe that only fits dogs. The pipe has two ends. One side has person A pushing dogs into the pipe - the source. The other side has person B pulling dogs out of the pipe - the sink. The source can push anything into the pipe that is a dog or more specialized than a dog, ie they can push in specific dog breeds like only terriers. So the source can treat the "Pipe of Dog" as a "Pipe of Terrier". It's okay beca…

I'm not exactly sure where the contra- and co- originally came from, but here's some cat-egory theory.

Now suppose you have a special pipe that when you push a dog into it, a cat comes out on the other end. This is called a dog-to-cat pipe. If you stick a dog-to-cat pipe to the end of a pipe of dog, then you get a pipe of cat (from the point of view of the sink end). The transformation varies with the direction of the dog-to-cat pipe. Hence covariant.

Now, what if you have a cat-to-dog pipe and stick it to the source end of a pipe of dog? Then you have a pipe of cat, from the source's point of view. The transformation varies against the direction of the cat-to-dog-pipe. Hence contravariant.

The example in the parent comment is with the more realistic example of a terrier-to-dog pipe or a dog-to-animal pipe. Of course, a pipe of dog is just a special name for a dog-to-dog pipe.

(Where this gets somewhat more complicated is when you have pipes which take pipes.)

Re: TypeScript 2.4

#37
post #12

Won't we stop transpiling everything once ES6 support (& modules) are ubiquitous? I kind of feel like this is when everybody converted codebases to CoffeeScript and are now stuck with having to undo that... Yes, I get strong typing has merits - but so does writing the native language.

I see a potential end-game being TypeScript becoming the new ECMAScript.

Even in that case it's easy to expect the Typescript compiler to remain in existence for its language services (such as intellisense) alone. (Just as Typescript is already used in "salsa" mode by many IDEs/Editors for providing language services for non-Typescript JS code today.)

That said, you would expect more of a middle ground like Python where Typescript type annotations become syntactically valid in ECMAScript but with no clear semantics at runtime, and Typescript would still be needed to compile/verify type assertions.

There's also the case that transpilers will likely remain test beds for both future features for the language and supporting complicated backwards compatible scenarios.

Re: TypeScript 2.4

#38
post #3

I only know a little bit of JavaScript, what's the best way to learn TypeScript? Read Eloquent JavaScript then some TS related stuff? Or is there a TypeScript for Dummies that don't know JS?

One way of learning TypeScript would be to fork a straightforward open source project, add type information and make the whole thing work with TS.

Re: TypeScript 2.4

#39
post #4

The string enums don't seem to work the same way as the number enums, there's no 2 way access. For example. enum Test { a } let a = Test.a; let b = Test[ 0 ]; // isn't available on the string ones I wonder why its like that.

[deleted]

Re: TypeScript 2.4

#40
post #4

The string enums don't seem to work the same way as the number enums, there's no 2 way access. For example. enum Test { a } let a = Test.a; let b = Test[ 0 ]; // isn't available on the string ones I wonder why its like that.

Interestingly, 2.3 will spit out what you want (but error on the invalid syntax).

  var Test;
  (function (Test) {
      Test[Test["a"] = "RED"] = "a";
  })(Test || (Test = {}));
While 2.4 doesn't error out, but omits the inner assignment, thus not allowing the lookup.

  var Test;
  (function (Test) {
      Test["a"] = "RED";
  })(Test || (Test = {}));
Post reply on HN