Tech Off Thread

4 posts

Tuple type

Back to Forum: Tech Off
  • User profile image
    staceyw

    I know the System.Tuple type in fx4.0 (http://msdn.microsoft.com/en-us/magazine/dd942829.aspx)  will be useful and glad it was added.  But if you had to make an argument for why you need it over creating a property class (e.g. DTO), what would the arguments be? Reducing number of classes is one (program size and complexity).  Having to stop and define a new type is another (programer speed).   However, having a concrete type can also be an advantage.  Please weight the pros and cons.  tia.

  • User profile image
    vesuvius

    This may help

  • User profile image
    rhm

    I haven't been following the .NET4 stuff that closely, but I'd assume they implemented tuples natively in the CLR in order to make the implementation of functional programming languages more straightforward. I wouldn't say there's any demand from the C#/VB.NET side of things for them, but maybe they'll be usefully integrated.

     

    The use of them in functional languages is not so much as a storage type (because most of them support records with named fields for that), but as a means to pass multiple values to a function in a single argument and to return multiple values from functions. 

  • User profile image
    vcomrhencke

    I actually developed my own tuple library in 2.0 that I've used for a few years, which ended up being very similar to what's coming in 4.0, so I'm actually in an oddly appropriate place to comment on this.  Smiley

     

    Tuples fit very nicely between concrete property classes and anonymous types in their degree of formality.  Like concrete classes, and unlike anonymous types, they can be easily returned from methods.  Like anonymous types, and unlike concrete classes, they are very simple to create and maintain.  (Anyone who has ever had to implement the whole Equals/GetHashCode/op_Equality/op_Inequality thing knows what I mean... ugh.)

     

    Tuples are great as quick and easy keys for dictionaries stored in class fields.  For example, let's say you needed a field in your class that would allow fast lookup of someone by name and favorite color.   (Ok, that's a little arbitrary, but pretend it's some multi-value key you didn't want to have to write and maintain a whole internal class for.)  

     

    Currently, you would need to do something along the lines of:

     

    private Dictionary<string, Dictionary<Color, Person>> nameAndFaveColorLookup;

     

    which isn't very fun to write code against, and doesn't programmatically scale very easily to adding multiple keys.

     

    Alternatively, you could do:

     

    private Dictionary<NameAndFavoriteColor, Person> nameAndFaveColorLookup;

    private struct NameAndFavoriteColor : IEquatable<NameAndFavoriteColor>
    {
    	//... insert properties and equality gunk here ...
    }

     

    which also isn't very fun because you have to maintain a bunch of equality stuff that's tedious and error prone, and is a lot of gruntwork for a simple lookup.

     

    With tuples, you could create a class field like:

     

    private Dictionary<Tuple<string,Color>,Person> nameAndFaveColorLookup;

     

    and be done.

     

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.