Editing Subtyping (section)

== Examples ==
[[Image:Inheritance.svg|thumb|right|350px|Example of subtypes: where bird is the supertype and all others are subtypes as denoted by the arrow in [[Unified Modeling Language|UML]] notation]]
A simple practical example of subtypes is shown in the diagram. The type "bird" has three subtypes "duck", "cuckoo" and "ostrich". Conceptually, each of these is a variety of the basic type "bird" that inherits many "bird" characteristics but has some specific differences. The [[Unified Modeling Language|UML]] notation is used in this diagram, with open-headed arrows showing the direction and type of the relationship between the supertype and its subtypes.

As a more practical example, a language might allow integer values to be used wherever floating point values are expected (<code>Integer</code> <: <code>Float</code>), or it might define a generic type <samp>Number</samp> as a common supertype of integers and the reals. In this second case, we only have <code>Integer</code> <: <code>Number</code> and <code>Float</code> <: <code>Number</code>, but <code>Integer</code> and <code>Float</code> are not subtypes of each other.

Programmers may take advantage of subtyping [[abstraction principle (programming)|to write code in a more abstract manner]] than would be possible without it. Consider the following example:

<syntaxhighlight lang="vbnet">
function max (x as Number, y as Number) is
    if x < y then
        return y
    else
        return x
end
</syntaxhighlight>

If integer and real are both subtypes of <code>Number</code>, and an operator of comparison with an arbitrary Number is defined for both types, then values of either type can be passed to this function. However, the very possibility of implementing such an operator highly constrains the Number type (for example, one can't compare an integer with a complex number), and actually only comparing integers with integers, and reals with reals, makes sense. Rewriting this function so that it would only accept 'x' and 'y' of the same type requires [[bounded polymorphism]].

Subtyping enables a given type to be substituted for another type or abstraction. Subtyping is said to establish an [[is-a]] relationship between the subtype and some existing abstraction, either implicitly or explicitly, depending on language support. The relationship can be expressed explicitly via inheritance in languages that support inheritance as a subtyping mechanism.

===C++===
The following C++ code establishes an explicit inheritance relationship between classes '''B''' and '''A''', where '''B''' is both a subclass and a subtype of '''A''', and can be used as an '''A''' wherever a '''B''' is specified (via a reference, a pointer or the object itself).

<syntaxhighlight lang=cpp>class A
{ public:
   void DoSomethingALike() const {}
};

class B : public A
{ public:
   void DoSomethingBLike() const {}
};

void UseAnA(A const& some_A)
{
   some_A.DoSomethingALike();
}

void SomeFunc()
{
   B b;
   UseAnA(b); // b can be substituted for an A.
}
</syntaxhighlight><ref name="Mitchell2002">
{{cite book
 | last=Mitchell
 | first=John
 | author-link=John C. Mitchell
 | title=Concepts in programming language
 | year=2002
 | publisher=Cambridge University Press
 | location=Cambridge, UK
 | isbn=0-521-78098-5
 | page=287
 | chapter=10 "Concepts in object-oriented languages"}}
</ref>

===Python===
The following python code establishes an explicit inheritance relationship between classes {{var|B}} and {{var|A}}, where {{var|B}} is both a subclass and a subtype of {{var|A}}, and can be used as an {{var|A}} wherever a {{var|B}} is required.

<syntaxhighlight lang="python">
class A:
    def do_something_a_like(self):
        pass

class B(A):
    def do_something_b_like(self):
        pass

def use_an_a(some_a):
    some_a.do_something_a_like()

def some_func():
    b = B()
    use_an_a(b)  # b can be substituted for an A.
</syntaxhighlight>

The following example, {{var|type(a)}} is a "regular" type, and {{var|type(type(a))}} is a metatype. While as distributed all types have the same metatype ({{var|PyType_Type}}, which is also its own metatype), this is not a requirement. The type of classic classes, known as {{var|types.ClassType}}, can also be considered a distinct metatype.<ref>{{cite web|author=Guido van Rossum|title=Subtyping Built-in Types|url=https://www.python.org/dev/peps/pep-0253/|access-date=2 October 2012}}</ref>

<syntaxhighlight lang="pycon">
>>> a = 0
>>> type(a)
<type 'int'>
>>> type(type(a))
<type 'type'>
>>> type(type(type(a)))
<type 'type'>
>>> type(type(type(type(a))))
<type 'type'>
</syntaxhighlight>

===Java===

In Java, '''is-a''' relation between the type parameters of one class or interface and the type parameters of another are determined by the extends and [[Interface (Java)|implements]] clauses.

Using the {{code|Collections}} classes, {{code|ArrayList<E>}} implements {{code|List<E>}}, and {{code|List<E>}} extends {{code|Collection<E>}}. So {{code|ArrayList<String>}} is a subtype of {{code|List<String>}}, which is a subtype of {{code|Collection<String>}}. The subtyping relationship is preserved between the types automatically. When defining an interface, {{code|PayloadList}}, that associates an optional value of [[generic type]] P with each element, its declaration might look like:

<syntaxhighlight lang=java>
interface PayloadList<E, P> extends List<E> {
    void setPayload(int index, P val);
    ...
}
</syntaxhighlight>

The following parameterizations of PayloadList are subtypes of {{code|List<String>}}:

<syntaxhighlight lang=java>
PayloadList<String, String>
PayloadList<String, Integer>
PayloadList<String, Exception>
</syntaxhighlight>