TypeScript 类型推导及类型兼容性

类型推导就是在没有明确指出类型的地方,TypeScript编译器会自己去推测出当前变量的类型。

例如下面的例子:

let a = 1;

我们并没有明确指明a的类型,所以编译器通过结果反向推断变量a的类型为number,这种推断发生在初始化变量和成员,设置默认参数值和函数有返回值时。

大多数情况下,类型推导是直截了当的,但也有很复杂的情况,例如需要去匹配参数来推测类型。

  最佳通用类型

当需要从几个表达式中推断类型时候,会使用这些表达式的类型来推断出一个最合适的通用类型。例如,

let x = [0, ‘fanqi‘, null];  //(string | number)[] 

为了推断x的类型,我们必须考虑所有元素的类型。 这里有三种选择: number、stringnull。 计算通用类型算法会考虑所有的候选类型,并给出一个兼容所有候选类型的类型。这个例子就是(string | number)[]。

由于最终的通用类型取自候选类型,有些时候候选类型共享相同的通用类型,但是却没有一个类型能做为所有候选类型的类型。例如:

let zoo = [new Rhino(), new Elephant(), new Snake()];

这里,我们想让zoo被推断为Animal[]类型,但是这个数组里没有对象是Animal类型的,因此不能推断出这个结果。 为了更正,当候选类型不能使用的时候我们需要明确的指出类型:

let zoo: Animal[] = [new Rhino(), new Elephant(), new Snake()];

如果没有找到最佳通用类型的话,类型推断的结果为联合数组类型,(Rhino | Elephant | Snake)[]

  上下文类型

TypeScript类型推论也可能按照相反的方向进行。 这被叫做“按上下文归类”。按上下文归类会发生在表达式的类型与所处的位置相关时。比如:

window.onmousedown = function(mouseEvent) {
    console.log(mouseEvent.button);  //<- Error
};

这个例子会得到一个类型错误,TypeScript类型检查器使用Window.onmousedown函数的类型来推断右边函数表达式的类型。 因此,就能推断出 mouseEvent参数的类型了。 如果函数表达式不是在上下文类型的位置, mouseEvent参数的类型需要指定为any,这样也不会报错了。

如果上下文类型表达式包含了明确的类型信息,上下文的类型被忽略。 重写上面的例子:

window.onmousedown = function(mouseEvent: any) {
    console.log(mouseEvent.button);  //<- Now, no error is given
};

这个函数表达式有明确的参数类型注解,上下文类型被忽略。 这样的话就不报错了,因为这里不会使用到上下文类型。

上下文归类会在很多情况下使用到。 通常包含函数的参数,赋值表达式的右边,类型断言,对象成员和数组字面量和返回值语句。 上下文类型也会做为最佳通用类型的候选类型。比如:

function createZoo(): Animal[] {
    return [new Rhino(), new Elephant(), new Snake()];
}

这个例子里,最佳通用类型有4个候选者:AnimalRhinoElephantSnake。 当然, Animal会被做为最佳通用类型。

  类型兼容性

TypeScript里的类型兼容性是基于结构子类型的。 结构类型是一种只使用其成员来描述类型的方式。 它正好与名义(nominal)类型形成对比。(译者注:在基于名义类型的类型系统中,数据类型的兼容性或等价性是通过明确的声明和/或类型的名称来决定的。这与结构性类型系统不同,它是基于类型的组成结构,且不要求明确地声明。) 看下面的例子:

interface Person {
    name: string;
}

class Father {
    name: string;
}

let person: Person;
// OK, because of structural typing
person = new Father();

在使用基于名义类型的语言,例如C#或Java中,这段代码会报错,因为Father类并没有明确说明其实现了Person接口。

TypeScript的结构性子类型是根据JavaScript代码的典型写法来设计的。 因为JavaScript里广泛地使用匿名对象,例如函数表达式和对象字面量,所以使用结构类型系统来描述这些类型比使用名义类型系统更好。

  关于可靠性的注意事项

我们可以看到在以上的类型中,只要满足了子结构的描述,那么它就可以通过编译时检查,所以TypeScript的设计思想并不是满足正确的类型,而是满足能正确通过编译的类型,这就造成了运行时和编译时可能存在类型偏差。

所以TypeScript的类型系统允许某些在编译时无法确认其安全性的操作。当一个类型系统具有此属性时,被认为是“不可靠”的。而TypeScript允许这种不可靠行为的发生是经过仔细考虑的。下面我们会解释为什么需要这种特性。

  开始

TypeScript结构化类型系统的基本规则是,如果x要兼容y,那么y至少具有与x相同的属性。例如:

interface Person {
    name: string;
}

let person: Person;
let y = { name: ‘fanqi‘, age: 25};
person = y; 

当将y赋值给person时,编译器会检查person中的每个属性,看是否能在y中也找到对应的属性。 在这个例子中,编译器发现y中也含有name属性,那赋值就是正确的,即使事实上并不准确。<br />

检查函数参数时使用相同的规则:

相关推荐