A guide to using the immutable classes: Tuple

! Warning: this post hasn't been updated in over three years and so may contain out of date information.

This is the first of a set of five tutorial articles covering the collections.immutable framework. This article covers the simplest of the classes: Tuple.

Imagine you have a flash or flex-based front end to an address and telephone look-up system. Class Lookup has two methods:

Whilst this code is OK, it suffers from scalability flaws. Firstly, having released our array into the wild of the rest of the application, we can no longer control it. There is nothing to stop code modifying it. The bigger the application, the more likely this will happen and the more difficult it becomes to track down bugs that arise from it. Secondly, if the lookup of the data takes time, we may well cache the array inside an instance of Lookup. If the array is modified, the cache becomes corrupted. This forces us to either create copies of the array, or not to cache through worries of corruption.

There is a third solution though and that is to use some form of immutable data type, ie one that cannot be modified after creation. If so inclined you could create read-only value object classes. eg:

Such classes have their advantages (they are type-safe, can be well documented etc), but they also have disadvantages (time-consuming to write & test and there can be problems with maintaining code if they change over time). These advantages and disadvantages of course touch on the debate of dynamic versus static typing. This leads neatly to the Tuple class within the collections.immutable package, as it offers a dynamic solution to the problem.

The Tuple class takes zero or more parameters in its constructor and creates an basic immutable list from them. So we can rewrite the original example code as:

If we then made a call to lookupNameAndAddress, eg:

then we can access the name via d[0] and the address via d[1] just as we could with the array. Trying to change the values though (eg d[0] = “New Name”) will result in an error being thrown.

In addition to the [] notation, Tuples in the collections.immutable package also support the scala-style _<index> notation. Unlike assessing the elements via [] though, the index for the underscore notation start with 1. So the following are equivalent:

And that is just about it for Tuples. They are deliberately simple types with a specific purpose: returning a dynamic, but immutable, set of values from a function.

5 thoughts on “A guide to using the immutable classes: Tuple

  1. so would you then create enumerations like:

    public static const NAME:uint = 0;
    public static const ADDRESS:uint = 1;



  2. This is exactly how C# implements anonymous types at the moment 🙂

    For .net tuples they use fields Item1, ItemN

  3. It’s a pity the _ notation starts with 1. It really should be consistent with the rest of the language. Luckily, more than half the occasions in which I’ve been wishing for Tuples in AS don’t require addressing the tuple’s elements dynamically, so I won’t have to mix the notations.

  4. @Neil,

    There are all sorts of problems with using int constants for enums. Hopefully I’ll be releasing my enums preprocessor in a couple of months, which will handle enums in the best way possible (IMO 🙂 ).

  5. @wallacoloo

    If you want 0-based indexes, use tuple[0], tuple[1] etc. The _1, _2 notation is there more as a nod to the functional lanugaes that inspired the Tuple class.

    Alternatively, download the source and change the code to start with _0. It’s open-source, so you are free to modify it and redistribute it in any way you like.

Comments are closed.