[Next] [Previous] [Up] [Top] [Contents] [Index]

4.3 Matching Against Type Patterns

4.3.2 Upper Bound Type Patterns

If the upper bound type of a formal or (explicit or implicit) type parameter is parameterized, each parameter type may itself contain an implicit type binding; upper bound types are themselves type patterns. In general, each parami has the same form as a formal type:

'Ti <= typei[param1, ..., paramN]
Like a formal type, if the <= type[...] upper bound is omitted, it defaults to any. Also like a formal type, the leading 'T <= prefix can be omitted. However, there is an important semantic distinction between a parameter of the form 'T <= type[...] and a parameter of the form type[...]. If the 'T <= prefix is omitted, then argument types matching the type pattern must have parameters that match type[...] exactly; for parameters of the form 'T <= type[...], matching types need only be a subtype of type[...]. To illustrate the distinction, consider the following two methods:

method detabify_all_1(s:array[string]):void { ... }
method detabify_all_2(s:array['T <= string]):void { ... }
The first method takes an argument s that is a subtype of array of string, i.e., any object that satisfies the interface of array of string. In particular, if array supports a store operation, then any value of type string must be able to be stored into the array s.

The second method places different constraints on its argument. It takes an array of things of some type T, where T is a subtype of string. So a value of type array[m_string], where m_string is some subtype of string, would be a legal argument to the second method. Such an argument would not be legal to the first method, however, since mutable arrays of mutable strings is not a subtype of mutable arrays of generic strings; a generic string cannot safely be stored into an array of mutable strings. For the second method, any value of type T can be stored safely into the argument array. Deciding the exact form of a parameterized type declaration can be rather subtle, and we need to gather more experience with the language to assess how well programmers are able to pick an appropriate type declaration. Type inference could help suggest the most-general type for a method, given its implementation.

The Cecil Language: Specification and Rationale, Version 2.1 - 25 MARCH 1997
[Next] [Previous] [Up] [Top] [Contents] [Index]

Generated with Harlequin WebMaker