Open Credo

February 28, 2017 | Software Consultancy

Some Uses For Type Aliases in Kotlin 1.1

As Kotlin’s 1.1 release draws closer, I’ve been looking at some of the new language features it supports. Type aliases may seem like a relatively minor feature next to coroutines, but as I will show in this blog post, they can open up a new programming idiom, particularly when combined with extension functions.

WRITTEN BY

Dominic Fox

Dominic Fox

Some Uses For Type Aliases in Kotlin 1.1

Introducing Type Aliases

As Kotlin’s 1.1 release draws closer, I’ve been looking at some of the new language features it supports. Type aliases may seem like a relatively minor feature next to coroutines, but as I will show in this blog post, they can open up a new programming idiom, particularly when combined with extension functions.

An immediately useful consequence of type aliases is that common types can be given aliases that more clearly communicate intent:

This can save us having to create wrapper classes like:

However, we cannot use type aliases to constrain parameters: a function accepting a PasswordHash parameter will accept any String value for that parameter. So we can assign freely, but also incorrectly:

Type aliases at this level are like a sort of colour-coding on types. They’re invisible to the underlying type system, which sees things only in black-and-white, so they’re neither checked by the compiler nor visible at run-time using reflection. However, they’re very convenient for the programmer. In particular, they enable us to express the domain of some part of a program in a very concise way:

Reading these type declarations, we know the fundamental types and type transformations that the part of the program that uses them is going to be about.

Note the data class at the end. If Kotlin supported a tuple construct, we might be able to write something like:

However, tuples were deliberately removed from Kotlin, in favour of data classes which provide explicit property names (rather than relying on positional indexing for properties). We could define Credentials like this:

but unless we wanted to use the semantics of Pair when handling Credentials (i.e. the a to b infix operator for constructing Pairs, and the interaction between Pair<K, V> and Map<K, V>), this would sacrifice the clarity of having properties named “username” and “passwordHash” (rather than “first” and “second”) to little advantage.

This highlights another important feature of type aliases: the alias has identical semantics to the aliased type. A Password behaves just like a String, and can be used anywhere a String can be used – and vice versa. A type and its alias are isomorphic.

Adding extension functions

In the example above, there is a relationship between Username, Password, HashFunction and Credentials, namely that a HashFunction can be used to make Credentials out of a Username and a Password:

Extension functions enable us to associate this function with the HashFunction type itself, so that anywhere we have a HashFunction (or a function from Password to PasswordHash) we can call this function as a method on it:

This is a powerful feature, but it has some pitfalls.Because Password and PasswordHash are both aliases for String, we have in fact added this extension function to every function with the signature (String) -> String: we are saying that every such function can be treated as a hash function for the purposes of generating credentials. There might be a legitimate worry here about namespace pollution – how is the programmer bringing up the autocomplete on String::intern to interpret the fact that this now has a makeCredentials function attached to it?

However, we can mitigate this by scoping the extension function very tightly to the context in which it is actually used – within the specific package, class or object that deals with credential handling.

There is an echo here of Scala’s implicit conversions, which similarly enable common types (and type-classes) to be ornamented with new features in an ad hoc fashion; and there are some of the same pitfalls, too. If the import which brings the makeCredentials function into scope goes missing, there is no obvious way to find it based on the literal type of the receiver. If, however, we have declared that type to be HashFunction rather than just (String) -> String, then by keeping the extension function definition close to the type alias declaration we can at least point the maintenance programmer (likely ourselves in six months’ time) in the right direction.

Compare the more traditional approach, based on inheritance:

The difficulty here is that we cannot then say:

but must settle for the comparatively awkward:

What we lose is the naturalness of being able to implement a hash function simply as a function – it puts a layer of “object bureaucracy” between us and the Kotlin type system.

Higher-order functions with type aliases

Let’s drop the extension function, in this case, and try an alternative approach:

The function hashingCredentialsBuilder is a higher-order function, one which takes a function as its input and returns a function as its output; its purpose is to “promote” a HashFunction to a CredentialsBuilder. This suggests a general pattern where we define types and functions between types using type aliases, and use higher-order functions to compose function types together.

Here’s an example, where we build up logically towards a function that is able to build credentials out of validated input from any “IO Context” that knows how to issue a prompt and receive an answer. First of all we define an IOContext:

Next, we stir in validation:

Now we can define input readers for usernames and passwords:

The final step is to assemble these together into an input reader for credentials. Here, we introduce an extension function on InputReader, combine, to reduce clutter a bit :

This is a significant departure from the interfaces-and-concrete-classes style of program composition familiar from Java (and, in particular, Java with Spring). The individual pieces are all extremely small, and the logic of how they are combined is expressed through type aliases and higher-order functions. Both the domain of the program and its operations are captured in type aliases, which can make it easy to see at a glance what the program does. Following this approach, we can use type aliases to provide a kind of module-level specification of the behaviour of regions of code.

Extension functions revisited

We can see here that type aliases provide a bridge between general purpose types, such as String or (String) -> Int, and specialised types, such as explicitly-defined interfaces and classes. If a class is merely a “wrapper” of some value, then we can replace it with a type alias and extension methods, so that:

becomes:

If a class provides a single behaviour, we can replace it by aliasing a function type:

Here, however, we cannot so easily wire in an addUser function, because there is no guarantee that a UserRegistry will be backed by a map – an extension function will have no access to its internals. Here’s a possible implementation (with some obvious performance limitations):

This approach can be useful if you want to pass general-purpose types in and out of a module of your program, but assign them a special meaning and associate special functionality with them internally – it eliminates a layer of “wrapping” and “unwrapping” at the API boundary.

Managing change

Suppose we decided that we wanted to store a password hash as an Array<Byte> rather than a String. By changing the typealias which defines PasswordHash, we can immediately update all of the other types which depend on it. Similarly, provided we have defined Prompt as an alias of String, we can replace a monolingual prompt with an internationalised one:

Equally, we can replace a type alias with a fully-fledged class or interface when the type takes on more structure. Suppose we move from a multi-user system to a multi-tenanted one, such that each user’s identity also carries with it the identity of the tenant who manages the user. We might then move from typealias UserId = UUID to:

If we had simply used UUID as our type for user ids, then the declared type of UserRegistry would have to change from (UUID) -> User to (UserId) -> User. Because the type was aliased, however, no change is necessary. Any piece of code that simple passes a UserId through without inspecting or modifying it will continue to function without alteration.

Conclusion

I hope I have shown a range of possible uses for type aliases, ranging from gentle semantic colouring (and elimination of “stringly-typed” code) to support for a highly functional approach to structuring programs. How far you want to take it in your own code is up to you, but the advantages of type aliasing for managing changes in the types handled by a program are clear. Extension methods defined on type aliases are powerful but dangerous (or, if you prefer, dangerous but powerful). Used with care, however, they can make programs more rather than less readable and maintainable. It’s a good idea to play around with the techniques demonstrated here, and get a feel for what makes sense in your environment and what doesn’t, before trying to decide what “best practice” might be.

RETURN TO BLOG

SHARE

Twitter LinkedIn Facebook Email

SIMILAR POSTS

Blog