TypeScript Typing

I have to admit that I'd never had any particular interest in JavaScript "superset-style" languages. I've loved JavaScript since I first understood how its base features: prototypes, object expansion and closures worked, and as over the years it has been getting more and more features, I'd never seen the point of moving to one of these "compile to javascript" languages (CoffeeScript, TypeScript...). With this in mind, my only reason to learn TypeScript seemed to be that it's becoming almost compulsory in some environments.

Well, I have to say that I'm amazed. The first beautiful surprise is that as it incorporates all the last-generation ES features, you can just use it as a "javascript version X" to "javascript version X-n" compiler. In that sense it's a nice replacement for Babel.js. It's interesting for example to see the different compiled code of a source that uses async/await. Compiling to es2016 will use a generator, compiling to es2017 will directly use async/await. Apart from this, some people will just use it as if it just were a sort of statically-typed Javascript.

This statically-typed vision is pretty limiting. You can use the language like that if you want, but indeed the "typing discipline" used by TypeScript is much more than that. You'll read in several places that TypeScript uses Duck Typing, well, from my understanding this is not correct, it uses Structural Typing. Even the TypeScript documentation does not seem to care and uses both terms as synonymous here, so I'll try to explain how I see the difference between both terms. It's normally said that Structural Typing is Compile-time Duck Typing, but I think the thing is a bit more complex. This article quite a bit of light on it.

Duck Typing. Duck Typing (like in JavaScript) only cares about the properties or methods that you are accessing (or will be accessing) at runtime. You don't define contracts (specify the type of an argument or variable), you just try to access to a property/method and if it fails you get an error. This is normally done at runtime and that's why we associate Duck Typing with dynamic languages, but it seems there are languages which compilers can do these checks at compile time: C++ and D templates

Structural Typing. This has been a pretty interesting discovery for me. You define contracts (for example the type of arguments to your method) and these contracts are checked at compile-time. In TypeScript you define these contracts via classes, interfaces or just via inline type definitions. The important thing is that contrary to what is done in C# or Java, in order to verify that contract the compiler will not check if the object is an instance of a class in which type hierarchy you can find the class or interface of the contract (this is called nominal typing, because you are checking type names). What the TypeScript compiler does is checking Type compabiliby by checking the shape (structure) of the object with the shape defined by the class or interface. If the shape matches (the object has the requested methods and properties), the contract is fullfilled, regardles of the names of the types in that object type hierarchy.

An interesting point is that with runtime Duck Typing a calling a function passing it the same object could succeed of fail depending of other factors, for example in this JavaScript code the first call works fine, but the second one throws an exception:

function getTax(item){
 if (salesSeason){
  return 0.10 * item.getSalesPrice(); 
 }
 else{
  return 0.10 * item.getPrice(); 
 }
}

var salesSeason = false;
let item = {
 name: "black jeans",
 getPrice(){return 21;}
};
getTax(item);//Works fine

salesSeason = true;
getTax(item); //throws exception, TypeError: item.getSalesPrice is not a function

However, in this TypeScript code Structural Typing will make the compiler give us errors for both calls:

interface ISalesItem{
 getPrice(): number;
 getSalesPrice(): number;
}

function getTax(item: ISalesItem){
 if (salesSeason){
  return 0.10 * item.getSalesPrice(); 
 }
 else{
  return 0.10 * item.getPrice(); 
 }
}

var salesSeason = false;
let item = {
 name: "black jeans",
 getPrice(){return 21;}
};
getTax(item); //compiler error

salesSeason = true;
getTax(item); //compiler error

Just to end this post, another beautiful idea in TypeScript is that the compiler was designed since its inception with a Language Service layer. I guess it was a quite natural decision for Anders Hejlsberg, that at that time had been working very hard on Roslyn.