In type theory, an intersection type can be allocated to values that can be assigned both the type σ {\displaystyle \sigma } and the type τ {\displaystyle \tau } . This value can be given the intersection type σ ∩ τ {\displaystyle \sigma \cap \tau } in an intersection type system. Generally, if the ranges of values of two types overlap, then a value belonging to the intersection of the two ranges can be assigned the intersection type of these two types. Such a value can be safely passed as argument to functions expecting either of the two types. For example, in Java the class Boolean implements both the Serializable and the Comparable interfaces. Therefore, an object of type Boolean can be safely passed to functions expecting an argument of type Serializable and to functions expecting an argument of type Comparable. Intersection types are composite data types. Similar to product types, they are used to assign several types to an object. However, product types are assigned to tuples, so that each tuple element is assigned a particular product type component. In comparison, underlying objects of intersection types are not necessarily composite. A restricted form of intersection types are refinement types. Intersection types are useful for describing overloaded functions. For example, if number => number is the type of function taking a number as an argument and returning a number, and string => string is the type of function taking a string as an argument and returning a string, then the intersection of these two types can be used to describe (overloaded) functions that do one or the other, based on what type of input they are given. Contemporary programming languages, including Ceylon, Flow, Java, Scala, TypeScript, and Whiley (see comparison of languages with intersection types), use intersection types to combine interface specifications and to express ad hoc polymorphism. Complementing parametric polymorphism, intersection types may be used to avoid class hierarchy pollution from cross-cutting concerns and reduce boilerplate code, as shown in the TypeScript example below. The type theoretic study of intersection types is referred to as the intersection type discipline. Remarkably, program termination can be precisely characterized using intersection types. Consequently, type inference for infinite-intersection types is undecidable, but it is decidable for all finite rank intersection types.
TypeScript example TypeScript supports intersection types, improving expressiveness of the type system and reducing potential class hierarchy size, demonstrated as follows. The following program code defines the classes Chicken, Cow, and RandomNumberGenerator that each have a method produce returning an object of either type Egg, Milk, or number. Additionally, the functions eatEgg and drinkMilk require arguments of type Egg and Milk, respectively.
The following program code defines the ad hoc polymorphic function animalToFood that invokes the member function produce of the given object animal. The function animalToFood has two type annotations, namely ((_: Chicken) => Egg) and ((_: Cow) => Milk), connected via the intersection type constructor &. Specifically, animalToFood when applied to an argument of type Chicken returns an object of type Egg, and when applied to an argument of type Cow returns an object of type Milk. Ideally, animalToFood should not be applicable to any object having (possibly by chance) a produce method.
Finally, the following program code demonstrates type safe use of the above definitions.
The above program code has the following properties:
Lines 1–3 create objects chicken, cow, and randomNumberGenerator of their respective type. Lines 5–7 print for the previously created objects the respective results (provided as comments) when invoking produce. Line 9 (resp. 10) demonstrates type safe use of the method animalToFood applied to chicken (resp. cow). Line 11, if uncommented, would result in a type error at compile time. Although the implementation of animalToFood could invoke the produce method of randomNumberGenerator, the type annotation of animalToFood disallows it. This is in accordance with the intended meaning of animalToFood. Line 13 (resp. 15) demonstrates that applying animalToFood to chicken (resp. cow) results in an object of type Egg (resp. Milk). Line 14 (resp. 16) demonstrates that applying animalToFood to cow (resp. chicken) does not result in an object of type Egg (resp. Milk). Therefore, if uncommented, line 14 (resp. 16) would result in a type error at compile time.
Comparison to inheritance The above minimalist example can be realized using inheritance, for instance by deriving the classes Chicken and Cow from a base class Animal. However, in a larger setting, this could be disadvantageous. Introducing new classes into a class hierarchy is not necessarily justified for cross-cutting concerns, or maybe outright impossible, for example when using an external library. Imaginably, the above example could be extended with the following classes:
a class Horse that does not have a produce method; a class Sheep that has a produce method returning Wool; a class Pig that has a produce method, which can be used only once, returning Meat. This may require additional classes (or interfaces) specifying whether a produce method is available, whether the produce method returns food, and whether the produce method can be used repeatedly. Overall, this may pollute the class hierarchy.
Comparison to duck typing The above minimalist example already shows that duck typing is less suited to realize the given scenario. While the class RandomNumberGenerator contains a produce method, the object randomNumberGenerator should not be a valid argument for animalToFood. The above example can be realized using duck typing, for instance by introducing a new field argumentForAnimalToFood to the classes Chicken and Cow signifying that objects of corresponding type are valid arguments for animalToFood. However, this would not only increase the size of the respective classes (especially with the introduction of more methods similar to animalToFood), but is also a non-local approach with respect to animalToFood.
… excerpt ends here. Continue reading the full article.
