jaredpar's WebLog : Generics

Immutable Collections and Compatibility with Existing Frameworks

Jared Parsons — Wed, 10 Dec 2008 16:00:00 GMT

When developing my immutable collections library, I spent a lot of time on usability. After all, if a library is not useful then what’s the point?

A big portion of usability is being able to work with existing frameworks and technologies. For .Net and collections that means items like Data binding, LINQ etc … Without integrating into popular technologies the usefulness of a particular library is severely impacted and hence usability decreases.

Most of the existing collection based infrastructures use the .Net collection interfaces as their form of abstraction. The most straight forward way to ensure compatibility is to implement these interfaces on the collections in question. In particular ICollection<T>, IList<T> and IEnumerable<T> are the main abstractions. Lets investigate which ones an Immutable collection should be implementing in order to effectively integrate into existing collection based infrastructures.

IEnumerable<T>

This is the easiest decision. IEnumerable<T> represents a read only, one element at time view on a sequence of objects. Immutable collections can easily and reliably implement a IEnumerable<T>. This is a no brainer. Implement.

ICollection<T>

This interfaces represents a general collection class. Unfortunately this interface is meant to represent a mutable collection class and implements such methods as Add, Clear and Remove. These methods cannot be implemented on an Immutable collection given the current design. All three of these methods are void returning methods because the collection is meant to be changed in place. Immutable collections can support these operations but it involves returning a new instance of the collection.

public sealed class ImmutableCollection<T> : ICollection<T> {
    public ImmutableCollection<T> Add(T item) {
        // Actually add 
        // ...
    }

    #region ICollection<T> Members

    void ICollection<T>.Add(T item) {
        var created = this.Add(item);
        // What to do with created???
    }

    ...
}

But wait! The interface does support a property named IsReadOnly. The intention of this property is to allow an interface to programmatically declare they do not support modifications. A read only collection can just implement this interface, throw a NotSupportedException for all of the mutable methods and return true for IsReadOnly and presto we have a suitable interface for an immutable collection.

Or do we?

The design for ICollection<T> with respect to read only or immutable collections is not optimal. It attempts to combine to separate behaviors into a single interface: mutable and readonly view of a collection. Dual purpose interfaces run into problems because it’s impossible to separate out the behaviors at compile time. This is especially problematic when the behaviors are conflicting. There is no way a read only collection can prevent itself from being passed to a function that expects a mutable collection at compile time. Nor can a consumer who intends to mutate a collection prevent a read-only collection from being passed.

static void DisplayForEdit<T>(ICollection<T> col) {
    // ...
    m_clearButton.Click += (x, y) => col.Clear(); 
}

static void Example1() {
    ImmutableCollection<int> col = ImmutableCollection.Create(new int[] { 1, 2, 3, 4 });
    DisplayForEdit(col);    // Will fail as soon as Clear is clicked
}

But isn’t it the responsibility of the user of ICollection<T> to verify that IsReadOnly is false before mutating a instance? Given the current design of ICollection<T> it is indeed both the responsibility of the consumer to verify this and the implementer to ensure they are not called incorrectly. The problem with putting responsibility on the consumer though is they have to 1) know about read only uses of ICollection<T> and 2) actually care about it.

A quick search of the BCL with reflector can give us evidence of how much consumers actually check for the read only scenario. For the search I used mscorlib, System, System.Xml, System.Data, System.Drawing and System.Core and System.Windows.Forms. And the number of classes which actually take into account ICollection<T>.IsReadOnly is … 1. System.Collections.ObjectModel.Collection<T>. That’s it.

So even if an immutable collection implements this interface in a read-only fashion there’s little chance anyone will be checking for it.

IList<T>

IList<T> inherits from ICollection<T> and hence suffers from all of the same problems

Decision Time

In order to facilitate usability with existing frameworks immutable collections are forced to implement interfaces for which they have no possible way of implementing properly. If collections implement these interfaces they will be trading usability for compile time validation. Even worse is the conversion is implicit which prevents even basic searches for places this conversion occurs. This is a heavy price to pay for compatibility.

After debating this for awhile I decided that loss of compile time validation was a too heavy of a price to pay for the default scenario. But trading away usability was also unacceptable. As a compromise I opted for adding a compatibility layer to the collections. Instead of implementing the ICollection<T> and IList<T> collections directly I created a set of proxy objects that implement the interfaces on behalf of the immutable collections.

In order to centralize this effort I created a factory class, CollectionUtility, which contains appropriate overloads for all of my immutable collection classes [1].

public static class CollectionUtility {
    public static IEnumerable<T> CreateEmptyEnumerable<T>();
    public static IEnumerable<T> CreateEnumerable<T>(T value);
    public static ICollection<T> CreateICollection<T>(IReadOnlyCollection<T> col);
    public static IDictionary<TKey, TValue> CreateIDictionary<TKey, TValue>(IReadOnlyMap<TKey, TValue> map);
    public static IList<T> CreateIList<T>(IReadOnlyList<T> list);
    public static ICollection CreateObjectICollection<T>(IReadOnlyCollection<T> col);
    public static IDictionary CreateObjectIDictionary<TKey, TValue>(IReadOnlyMap<TKey, TValue> map);
    public static IList CreateObjectIList<T>(IReadOnlyList<T> list);
    public static IEnumerable<int> GetRangeCount(int start, int count);
}

The proxy objects live as private inner classes inside CollectionUtility. They implement the collection interfaces in the most read-only way possible. When confronted with mutating calls, the proxies throw NotSupportedException.

So at the end of the day I have compile time validation for immutable collections. If a developer wants to use them in a less than safe scenario it requires an explicit conversion.

static void Example2() { 
  var col = ImmutableCollection.Create(new int[] { 1, 2, 3, 4 }); 
  // Still fails, but explicit conversion required 
  DisplayForEdit(CollectionUtility.CreateICollection(col)); 
  }

I feel like this as an appropriate tradeoff. In the worst case scenario, a developer can search for all accesses of the CollectionUtility class and find places where a proxy is being created.

Next time, lets take a look at a different way of approaching an interface hierarchy for a set of collections. One that will allow us to avoid this problem altogether going forward.

[1] It actually contains overloads for a set of truly read only collection interfaces that I wrote for my library but we’ll get to that another time.

Edit: Updated the exception to be NotSupportedException

Gotcha: Generic overload resolution when called generically

Jared Parsons — Mon, 14 Apr 2008 15:30:07 GMT

Both VB and C# have a feature of generic overload resolution that is fairly helpful and yet a source of gotchas. Lets say you have two methods with the same number of arguments. One method has arguments with generic types and the other does not. For Example:

    class C1<T> {
        public void F1(int ival) {
            Console.WriteLine("Non-generic F1");
        }
        public void F1(T val) {
            Console.WriteLine("Generic F1");
        }
    }

Imagine what happens when we have a C1<int> and call F1(5). Which method should the compiler bind to? Both VB and C# when presented with this type of situation will choose the non-generic version.

            v1.F1(5);           // Binds to Non-generic F1
            v2.F1("foo");       // Binds to Generic F1

At a glance we might think that we can provide specialized behavior for a subset of types that are interesting (similar to C++ template specialization). If VB/C# will bind to our non-generic version then we don't have to due ugly type switching to implement different behavior for certain types. Unfortunately we would be wrong.

This type of overload resolution only happens if the compiler can statically verify that the argument matches a non-generic overload. So if we call F1 generically it will not bind to the non-generic overload.

        static void TestOverload<T>(C1<T> weird, T value) {
            weird.F1(value);
        }

        static void Main(string[] args) {
            var v1 = new C1<int>();
            var v2 = new C1<string>();

            TestOverload(v1, 5);        // Binds to Generic F1
            TestOverload(v2, "foo");    // Binds to Generic F1
        }

Design Guidelines: Provide type inference friendly Create function for generic objects

Jared Parsons — Fri, 11 Apr 2008 15:24:50 GMT

Really this guideline is a bit longer but putting it all in a blog title seemed a bit too much. The full guideline should read: "If a generic class constructor arguments contain types of all generic parameters, provide a static method named Create on a static class of the same class name as the generic class which takes the same arguments and calls the constructor." Quite a mouth full.

Lets look at a specific example with Tuples. Tuples are generic with respect to the values they are representing. Without any type inference help we would have to write the following code to create a simple tuple.

            var tuple = new Tuple<int, string>(5, "astring");

Not too bad because we are using simple types. But what happens when we are using really long type names?

            var tuple2 = new Tuple<string,Dictionary<string, List<int>>>(val1, val2);

As we can see, the code is getting quite a bit uglier. This pattern is in fact not maintainable once we start using un-namable types such as anonymous types or generics of anonymous types.

The problem here is we are not leveraging the compilers type inference capabilities. The compiler can easily infer the types of a tuple argument and hence create a tuple. We just need to provide a mechanism to do so. The best way is to define a static method on a static class with the same name as the generic. Lets call this method Create.

    public static class Tuple {
        public static Tuple<TA, TB> Create<TA, TB>(TA valueA, TB valueB) { 
            return new Tuple<TA, TB>(valueA, valueB); 
        }
    }

The method Tuple.Create still has two generic parameters. However since we are providing a set of values which contain types for every generic parameter, the compiler can infer the generic arguments. Now we can create a Tuple without specifying any generic arguments. Because no types are specified this will work with any value in the code including un-namable types.

            var tuple = Tuple.Create(6, "astring");
            var tuple2 = Tuple.Create(6, new { name = "aname", value = 42 });

Have an IComparer but need an IComparable?

Jared Parsons — Wed, 09 Apr 2008 15:20:59 GMT

Previously we discussed the opposite problem. This is a lesser but often more frustrating problem because there is no, AFAIK, built in solution for the BCL. However it's problem that can be solved once and reused with a generic solution. IComparable<T> has all of the methods necessary implement IComparer<T>.

To work around this we'll create a new class that can wrap both a value and an instance of IComparable(Of T). Lets call it ComparerNode<T>. This class can be used wherever an IComparable<T> is needed.

Unfortunately generic classes will not provide a 1:1 mapping. However getting to the actual data is strongly typed and comes through a simple property.

   public sealed class ComparerNode<T> : IComparable<ComparerNode<T>> {
        private readonly IComparer<T> m_comparer;
        private readonly T m_value;

        public IComparer<T> Comparer {
            get { return m_comparer; }
        }

        public T Value {
            get { return m_value; }
        }

        public ComparerNode(IComparer<T> comparer, T value) {
            if (comparer == null) {
                throw new ArgumentNullException("comparer");
            }

            m_comparer = comparer;
            m_value = value;
        }

        public override int GetHashCode() {
            if (m_value == null) {
                return 0;
            }

            return m_value.GetHashCode();
        }

        public override bool Equals(object obj) {
            var other = obj as ComparerNode<T>;
            if (other == null) {
                return false;
            }

            return 0 == m_comparer.Compare(m_value, other.m_value);
        }

        #region IComparable<ComparerNode<T>> Members

        public int CompareTo(ComparerNode<T> other) {
            if (other == null) {
                return 1;
            }

            return m_comparer.Compare(m_value, other.m_value);
        }

        #endregion

        public static bool operator <(ComparerNode<T> left, ComparerNode<T> right) {
            return Comparer<ComparerNode<T>>.Default.Compare(left, right) < 0;
        }

        public static bool operator >(ComparerNode<T> left, ComparerNode<T> right) {
            return Comparer<ComparerNode<T>>.Default.Compare(left, right) > 0;
        }

        public static bool operator ==(ComparerNode<T> left, ComparerNode<T> right) {
            return EqualityComparer<ComparerNode<T>>.Default.Equals(left, right);
        }

        public static bool operator !=(ComparerNode<T> left, ComparerNode<T> right) {
            return !EqualityComparer<ComparerNode<T>>.Default.Equals(left, right);
        }
    }

    public static class ComparerNode {
        public static ComparerNode<T> Create<T>(IComparer<T> comparer, T value) {
            return new ComparerNode<T>(comparer, value);
        }

        public static ComparerNode<T> Create<T>(T value)
            where T : IComparable<T> {
            return new ComparerNode<T>(Comparer<T>.Default, value);
        }
    }

Tuples Part 8: Finishing up

Jared Parsons — Mon, 28 Jan 2008 05:37:18 GMT

There are only a few missing features from our tuple implementation. Mainly FxCop compliance, debugging support and test case code. The actual functional work is complete.

The one issue with FxCop compliance is the chosen names. Namely using A,B etc. FxCop, rightly, believes names should have more value. Accordingly, calling the generic argument corresponding to A, TA also causes the same issue. This is a design decision made from the begining. I don't believe changing the name to ValueA adds any more value than simply A. Therefore the warning for this will simply be suppressed.

Additionally FxCop doesn't like types with more than 3 generic parameters. This is also a design decision intentionally done and there is no avoiding it. It will be suppressed as well.

For debugging support a simple DebuggerDisplay attribute will be used. It will display the current value of all of the tuple values.

Here is the latest version of the full script which includes all of the new information. With the exception of a few small tweaks this is just the combination of the individual parts specified throughout these postings.

param ( [int]$tupleCount = 5,
[string]$namespace = "Tuples" )

$script:scriptPath = split-path -parent $MyInvocation.MyCommand.Definition
$script:lowerList = 0..25 | %{ [char]([int][char]'a'+$_) }
$script:upperList = 0..25 | %{ [char]([int][char]'A'+$_) }
$script:valueList = "1","42",'"bar"', '"foo"', 'true'

function script:Gen-FxCop
{
param ( [int]$code )

    switch ( $code )
    {
        1704 { '[SuppressMessage("Microsoft.Naming", "CA1704")]'; break }
        1005 { '[SuppressMessage("Microsoft.Design", "CA1005")]'; break }
        default: {$(throw "Invalid")}
    }
}

function script:Gen-Display
{
    param ( [int]$count )
    $OFS = ", "
    $p = [string](0..($count-1) | %{ "{0}={{{0}}}" -f $upperList[$_] })
    '[DebuggerDisplay("{0}")]' -f $p
}

function script:Gen-Property
{
param ( [int] $index = $(throw "Need an index"), [bool]$mutable = $false)

    if (-not $mutable )
    {
@"
    private readonly T{0} m_{1};
    $(Gen-FxCop 1704)
    public T{0} {0} {{ get {{ return m_{1}; }} }}

"@ -f $upperList[$index],$lowerList[$index]
    }
    else
    {
@"
    private T{0} m_{1};
    $(Gen-FxCop 1704)
    public T{0} {0} {{ get {{ return m_{1}; }} set {{ m_{1} = value; }} }}

"@ -f $upperList[$index],$lowerList[$index]
}
}

function script:Gen-Constructor
{
    param ( [int] $count = $(throw "Need a count"), [string]$className )
    $OFS = ','
    $list = [string](0..$($count-1) | %{ "T{0} value{0}" -f $upperList[$_]})
    "public $className($list) {"
    0..($count-1) | %{ "m_{0} = value{1};" -f $lowerList[$_],$upperList[$_] }
    "}"
}

function script:Gen-InferenceConstructor
{
    param ( [int] $count = $(throw "Need a count"), [string]$name )
    $OFS = ','
    $gen = "<" + [string](0..($count-1) | %{ "T"+$upperList[$_] }) + ">"
    $list = [string](0..$($count-1) | %{ "T{0} value{0}" -f $upperList[$_] })
    $argList = [string](0..$($count-1) | %{ "value{0}" -f $upperList[$_] })
    "public static partial class $name {"
    Gen-FxCop 1704
    "public static $name$gen Create$gen($list) { return new $name$gen($argList); } "
    "}"
}

function script:Gen-Equals
{
    param ( [int] $count = $(throw "Need a count"), [string]$name )
    $OFS = ','
    $gen = "<" + [string](0..($count-1) | %{ "T"+$upperList[$_] }) + ">"
    "public override bool Equals(object obj) { "
    "return Equals(obj as $name$gen); }"
    "public bool Equals($name$gen other) {"
    "if ( Object.ReferenceEquals(other,null) ) { return false; }"
    "if ("
    $OFS = "&&"
    [string](0..($count-1) | %{"EqualityComparer<T{0}>.Default.Equals(m_{1},other.m_{1})" -f $upperList[$_],$lowerList[$_] })
    ") { return true; }"
    "return false;"
    "}"
}

function script:Gen-GetHashCode
{
    param ( [int] $count = $(throw "Need a count") )
    "public override int GetHashCode() {"
    "int code = 0;"
    0..($count-1) | %{ "code += EqualityComparer<T{0}>.Default.GetHashCode(m_{1});" -f $upperList[$_],$lowerList[$_] }
    "return code;"
    "}"
}

function script:Gen-ITuple
{
    param ( [int] $count = $(throw "Need a count") )
    $OFS = ','
    $gen = "<" + [string](0..($count-1) | %{ "T"+$upperList[$_] }) + ">"
    $base = ""
    if ( $count -ne 1 )
    {
        $baseGen = "<" + [string](0..($count-2) | %{ "T"+$upperList[$_] }) + ">"
        $base = ": ITuple$baseGen"
    }
    else
    {
        $base = ": ITuple"
    }
    Gen-FxCop 1704
    if ( $count -gt 2 ) { Gen-FxCop 1005 }
    "public interface ITuple$gen $base {"
    Gen-FxCop 1704
    "T{0} {0} {{ get; }}" -f $upperList[$count-1]
    "}"
}

function script:Gen-TupleAccess
{
    param ( [int] $count = $(throw "Need a count"), [bool]$mutable )
    "public int Count { get { return $count; } }"
    "public object this[int index] { get { switch (index){ "
    0..($count-1) | %{ "case $($_): return m_$($lowerList[$_]);" }
    "default: throw new InvalidOperationException(""Bad Index"");"
    "} }"

    if ( $mutable )
    {
        "set { switch (index) {"
        0..($count-1) | %{ "case $($_): m_$($lowerList[$_]) = (T$($upperList[$_]))value; break;" }
        "default: throw new InvalidOperationException(""Bad Index"");"
        "} } "
    }
    "}"
}

function script:Gen-OpEquals
{
    param ( [int] $count = $(throw "Need a count"), [string]$name )
    $OFS = ','
    $gen = "<" + [string](0..($count-1) | %{ "T"+$upperList[$_] }) + ">"
    "public static bool operator==($name$gen left, $name$gen right) {"
    "return EqualityComparer<$name$gen>.Default.Equals(left,right); }"
    "public static bool operator!=($name$gen left, $name$gen right) {"
    "return !EqualityComparer<$name$gen>.Default.Equals(left,right); }"
}

function script:Gen-CompareTo
{
    param ( [int] $count = $(throw "Need a count"), [string]$name )
    $OFS = ','
    $gen = "<" + [string](0..($count-1) | %{ "T"+$upperList[$_] }) + ">"
    "public int CompareTo(object obj) {"
    "return CompareTo(obj as $name$gen); }"
    "public int CompareTo($name$gen other) {"
    "if ( Object.ReferenceEquals(other,null) ) { return 1; }"
    "int code;"
    0..($count-1) |
        %{ "code = Comparer<T{0}>.Default.Compare(m_{1},other.m_{1}); if (code != 0) {{ return code; }}" -f $upperList[$_],$lowerList[$_] }
    "return 0; }"
    "public static bool operator>($name$gen left, $name$gen right) { "
    "return Comparer<$name$gen>.Default.Compare(left,right) > 0; }"
    "public static bool operator<($name$gen left, $name$gen right) { "
    "return Comparer<$name$gen>.Default.Compare(left,right) < 0; }"
}

function script:Get-Tuple
{
    param ( [int] $count, [bool]$mutable = $false )
    $OFS = ','
    $gen = "<" + [string](0..($count-1) | %{ "T"+$upperList[$_] }) + ">"
    Gen-FxCop 1704
    Gen-Display $count
    if ( $count -gt 2 ) { Gen-FxCop 1005 }
    $name = "{0}Tuple" -f (Get-Ternary $mutable "Mutable" "")
    "public sealed class $name$gen : ITuple$gen,IEquatable<$name$gen>, IComparable<$name$gen>,IComparable {"
    (0..($count-1) | %{ Gen-Property $_ $mutable})
    Gen-Constructor $count $name
    Gen-TupleAccess $count $mutable
    Gen-Equals $count $name
    Gen-GetHashCode $count
    Gen-OpEquals $count $name
    Gen-CompareTo $count $name
    "}"
    Gen-InferenceConstructor $count $name
}

function Gen-TestTuple([int]$count, [string]$prefix)
{
    $OFS = ","
    $v = [string](0..($count-1) | %{ $valueList[$_]} )
    "[TestMethod]"
    "public void {0}Access{1}() {{" -f $prefix,$count
    "var t = $prefix.Create($v);"
    for ( $i = 0; $i -lt $count; ++$i )
    {
        "Assert.AreEqual({0},t.{1});" -f $valueList[$i],$upperList[$i];
    }
    "}"

    "[TestMethod]"
    "public void {0}GenericAccess{1}() {{" -f $prefix,$count
    "var t = $prefix.Create($v);"
    for ( $i = 0; $i -lt $count; ++$i )
    {
        ("Assert.AreEqual({0},t[{1}]);" -f $valueList[$i],$i);
    }
    "Assert.AreEqual({0},t.Count);" -f $i
    "}"

    "[TestMethod]"
    "public void {0}Equals{1}() {{" -f $prefix,$count
    "var t1 = $prefix.Create($v);"
    "var t2 = $prefix.Create($v);"
    "Assert.IsTrue(t1.Equals(t2));"
    "}"

    "[TestMethod]"
    "public void {0}NotEquals{1}() {{" -f $prefix,$count
    for ( $i = 0; $i -lt $count; ++$i )
    {
        $leftName = "t{0}_1" -f $i
        $rightName = "t{0}_2" -f $i
        $left = "var $leftName = $prefix.Create(" -f $i
        $right = "var $rightName = $prefix.Create(" -f $i
        for ( $v = 0; $v -lt $count; ++$v )
        {
            $left += "$v"
            if ( $v -eq $i )
            {
                $right += "-1"
            }
            else
            {
                $right += "$v"
            }

            if ( ($v + 1) -lt $count )
            {
                $left += ","
                $right += ","
            }
        }
        "$left);"
        "$right);"
        "Assert.AreEqual($leftName.GetType(), $rightName.GetType());"
        "Assert.IsFalse($leftName.Equals($rightName));"
    }
    "}"

    "[TestMethod]"
    "public void {0}CompareTest() {{ " -f $prefix
    "Assert.IsTrue($prefix.Create(1) < $prefix.Create(2));"
    "Assert.IsTrue($prefix.Create(2) > $prefix.Create(1));"
    "}"
}

$output =
@"
using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Diagnostics.CodeAnalysis;

namespace $namespace {
public interface ITuple {
int Count { get; }
object this[int index] { get; }
}
"@
$OFS = [Environment]::NewLine
$output += [string](0..($tupleCount-1) | %{ Gen-ITuple ($_+1) })
$output += [string](0..($tupleCount-1) | %{ Get-Tuple ($_+1) })
$output += [string](0..($tupleCount-1) | %{ Get-Tuple ($_+1) $true })
$output += "}"

$output > (join-path $scriptPath "Core\Tuple.cs")

$output =
@"
using System;
using System.Collections.Generic;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using $namespace;

namespace $($nameSpace)Test {

[TestClass]
public class TupleTest{
"@
$output += Gen-TestTuple $tupleCount "Tuple"
$output += Gen-TestTuple $tupleCount "MutableTuple"
$output += "}}"
$output > (join-path $scriptPath "TestCore\TupleTest.cs")

Tuples Part 6: Comparing

Jared Parsons — Tue, 22 Jan 2008 09:56:00 GMT

Part 5 produced equality tests for Tuples. This section will add comparison support through the IComparable<T> interface. Implementing comparable is very similar to adding equality support. Once again there is a generic class available to make all of the comparison decisions for us; Comparer<T>.

The implementation will compare objects in a left to right fashion. In this case the property corresponding to TA will be the left most, and TN the right most. If all properties are equal (Compare returns 0) then the two items will be determined to be equal and will return 0.

function script:Gen-CompareTo
{
    param ( [int] $count = $(throw "Need a count") )
    $OFS = ','
    $gen = "<" + [string](0..($count-1) | %{ "T"+$upperList[$_] }) + ">"
    "public int CompareTo(object other) {"
    "return CompareTo(other as Tuple$gen); }"
    "public int CompareTo(Tuple$gen other) {"
    "if ( Object.ReferenceEquals(other,null) ) { return 1; }"
    "int code;"
    0..($count-1) |
        %{ "code = Comparer<T{0}>.Default.Compare(m_{1},other.m_{1}); if (code != 0) {{ return code; }}" -f $upperList[$_],$lowerList[$_] }
    "return 0; }"
}

Once again the same questions arise about implementing IComparable<Tuple> vs IComparable<ITuple> (or both). The arguments are fairly similar and as a result I decided to skip implementing the ITuple version for now.

Tuples Part 5: Equality

Jared Parsons — Tue, 22 Jan 2008 09:31:18 GMT

Part 4 left us with a reusable, abstract and inference friendly Tuple class. The next step is to be able to test for Tuple equality.

For the Tuple implementation, two tuples will be defined as equal if all of their members are equal. Seems fairly straight forward. The trick is in the implementation. In addition to doing the typical override of Equals/GetHashCode the Tuple implementation will be implementing IEquatable<T> and overloading the standard equality operators.

Tuple members are all unconstrained generic classes which leaves us with a non-great starting point.

For instance what if we are dealing with value types? Is Equals() the best method to call? What if the type in question implements IEquatable<T> or has a well known IEqualityComparer<T>? What if one or both of the arguments are reference types and null? What if they're value types and equal to null?

Luckily there is an easy and straight forward solution. The BCL defines a class, EqualityComparer<T>, which will properly perform equality comparisons for objects of a particular type. This makes the Equals override very straight forward.

There is one small trick to implementing Equals correctly. The implementation explicitly uses Object.ReferenceEquals to check for null rather than ==. The reason being is once operator== is defined for the type Tuple, comparison for even null will bind to this operator. Part of checking for operator== will end up calling Equals and hence you can end in a stack overflow fairly quick. Note that our implementation of == will work around this but it's still safer to be explicit.

function script:Gen-Equals
{
    param ( [int] $count = $(throw "Need a count") )
    $OFS = ','
    $gen = "<" + [string](0..($count-1) | %{ "T"+$upperList[$_] }) + ">"
    "public override bool Equals(object obj) { "
    "return Equals(obj as Tuple$gen); }"
    "public bool Equals(Tuple$gen other) {"
    "if ( Object.ReferenceEquals(other,null) ) { return false; }"
    "if ("
    $OFS = "&&"
    [string](0..($count-1) | %{"EqualityComparer<T{0}>.Default.Equals(m_{1},other.m_{1})" -f $upperList[$_],$lowerList[$_] })
    ") { return true; }"
    "return false;"
    "}"
}

GetHashCode can also utilize EqualityComparer<T>.

Both of the operators are likewise straight forward. As before mentioned EqualityComparer<T> will properly check for null and then perform an Equals call so it can be used as the standard operator code.

function script:Gen-OpEquals
{
    param ( [int] $count = $(throw "Need a count") )
    $OFS = ','
    $gen = "<" + [string](0..($count-1) | %{ "T"+$upperList[$_] }) + ">"
    "public static bool operator==(Tuple$gen left, Tuple$gen right) {"
    "return EqualityComparer<Tuple$gen>.Default.Equals(left,right); }"
    "public static bool operator!=(Tuple$gen left, Tuple$gen right) {"
    "return !EqualityComparer<Tuple$gen>.Default.Equals(left,right); }"
}

In addition to the methods, the Tuple class generation must be changed to implement IEquatable<Tuple<>>.

Some will notice that the implementation forces the equality comparison to be against a Tuple<T> vs an ITuple<T>. There are a couple of reasons for this.

I have come up against specific scenarios where I wanted to compare Tuple<T> but not ITuple<T>. This is not saying they don't exist (they do). But I prefer to leave an implementation until I find a justification for implementing it.
By constraining to IEquatable<Tuple<T>> we are always comparing apples to apples. If you try and perform an Equals against ITuple<TA> you're leaving yourself open to comparing apples and oranges. Since ITuple<TA,TB> implements ITuple<TA> it is a valid target for the overload. This type of equality seems scenario dependent and as such I left it out for the time. Note with our current implementation it would be very easy to come back and add this later.
To make #2 even stranger, once MutableTuples are implemented an implemantation of IEquatable<ITuple<TA>> might actually be comparing Tuple<TA,TB,TC> to MutableTuple<TA>.

C# Lambda Type Inference

Jared Parsons — Fri, 14 Dec 2007 20:41:47 GMT

One of the limitations of C# type inference is that you cannot use it to infer the type of a lambda expression. For example, the following code will not compile

            var f = () => 4;

Normally this is not too much of an issue because you can just explicitly declare the type of the lambda expression.

            Func<int> f = () => 4;

However, this can be annoying at times. Once you start defining complex lambda expressions the Func/Action declaration can be quite convoluted. Even worse, if your lambda returns an anonymous type, there is no way to declare a Func<> with the anonymous type parameter because you cannot describe it's shape.

            Func<???> f = () => new { Name = "foo" };

This is fixable though by using type inference. The method is very similar to other anonymous type type tricks. While lambda type inference is not supported for variable declaration it is supported for parameters. C# supports return type inference so that can be used to type the variable.

        static Func<T> Lambda<T>(Func<T> del)
        {
            return del;
        }

        static void Main(string[] args)
        {
            var f = Lambda(() => new { Name = "foo" });
        }

Type Inference and IEnumerable

Jared Parsons — Tue, 27 Nov 2007 01:32:10 GMT

This is somewhat of a follow up on a previous post I did on the difference between IEnumerable(Of T) and the IEnumerable interfaces.

I've seen several people type in the following code and wonder if there was a fundamental bug in the type inference code.

    Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
        For Each cur In Controls
            cur.Text = "A Value"
        Next
    End Sub

This code will produce an error stating that "Text" is not a member of object. Users expected type inference to type the variable "cur" as Control. Unfortunately this is "By Design".

Much of the original .Net Framework was written before the CLR implemented support for generics. As a result all of the collection classes were loosely typed to Object by implementing IEnumerable. So in this case type inference will correctly type this as Object.

There are 2 ways to fix this problem.

Explicitly type the For Each variable to be the actual type of objects in the collection
Use a Shim to change the type of the collection. (see http://blogs.msdn.com/jaredpar/archive/2007/10/04/ienumerable-and-ienumerable-of-t.aspx)

Names of Anonymous Type Members

Jared Parsons — Sat, 10 Nov 2007 03:46:40 GMT

Recently I was asked how can you get a list of anonymous type member names given a query of anonymous types. The quick answer is that you can use a quick bit of reflection to get back the names.

    Public Function GetAnonymousTypeMemberNames(Of T)(ByVal anonymousType As T) As List(Of String)
        Dim type = GetType(T)
        Dim list = New List(Of String)
        For Each cur In type.GetProperties(Reflection.BindingFlags.Public Or Reflection.BindingFlags.Instance)
            list.Add(cur.Name)
        Next
        Return list
    End Function

The longer question is how can you get back a list of anonymous type member names given a query result? As long as you know the query will be populated you can just use the first member to get your result.

        Dim q = From it In "astring" Select a = it, b = it & "b"
        GetAnonymousTypeMemberNames(q.First())

However you can't guarantee that a query will always have data in it. Another route is to consider the contract of the From ... Select statement. This will produce a query which implements IEnumerable(Of T). For a query T will be the anonymous type that is generated[1]. We can query the metadata of the returned type to get the System.Type for the anonymous type regardless of the type actually implementing IEnumerable(Of T).

        Dim q = From it In "astring" Select a = it, b = it & "b"
        Dim enumerableInterface = GetType(IEnumerable(Of ))
        Dim enumerableType = q.GetType().GetInterface(enumerableInterface.FullName)
        Dim anonymousTypeType = enumerableType.GetGenericArguments(0)

[1] This is assuming that you didn't write a query which returns a field directly and avoids creating the anonymous type.

IEnumerable and IEnumerable(Of T) 2

Jared Parsons — Fri, 05 Oct 2007 18:43:06 GMT

Quick follow up to my earlier post. Fixing this issue in C# is even easier because of the existence of iterators.

        public static IEnumerable<object> Shim(System.Collections.IEnumerable enumerable)
        {
            foreach (var cur in enumerable)
            {
                yield return cur;
            }
        }

IEnumerable and IEnumerable(Of T)

Jared Parsons — Thu, 04 Oct 2007 21:29:08 GMT

IEnumerable(Of T) is a huge step up in the 2.0 framework from the original IEnumerable interface. It provides a typed enumeration which eliminates lots of nasty casts. The best part is that IEnumerable(Of T) is backwards compatible with IEnumerable (it inherits from it).

What's frustrating is that IEnumerable is not forwards compatible with IEnumerable(Of Object). This prevents you from using IEnumerable anywhere IEnumerable(Of Object) or an inferred IEnumerable<T> is expected even though they have almost the same interface. The framework couldn't take the same approach and have IEnumerable inherit IEnumerable(Of Object) because it would have broken any implementer on upgrade to the 2.0 framework.

The good news is this is easy to shim. Since IEnumerable(Of Object) and IEnumerable have virtually the same, it's easy to create a wrapper class that forwards the calls into the base enumerator.

The basic shim involves two classes

EnumerableShim - Implements IEnumerable(Of Object). This class wraps an IEnumerable object only has two methods.

    Public Function GetEnumerator() As System.Collections.Generic.IEnumerator(Of Object) Implements System.Collections.Generic.IEnumerable(Of Object).GetEnumerator
        Return New EnumeratorShim(m_enumerable.GetEnumerator())
    End Function

    Public Function GetEnumerator1() As System.Collections.IEnumerator Implements System.Collections.IEnumerable.GetEnumerator
        Return m_enumerable.GetEnumerator()
    End Function

EnumeratorShim - Implements IEnumerator(Of Object). This class wraps the IEnumerator object created above and implements the standard methods by forwarding all calls to the IEnumerator implementation. For example ...

        Public ReadOnly Property Current() As Object Implements System.Collections.Generic.IEnumerator(Of Object).Current
            Get
                Return m_impl.Current
            End Get
        End Property

Now whenever your stuck with and old framework collection that was not updated for generic support, you can use it in generic situations with a single indirection call.

        Dim list As New ArrayList
        ...
        SomeMethod(New EnumerableShim(list))

Casting to an Anonymous Type

Jared Parsons — Mon, 01 Oct 2007 18:15:00 GMT

This discussion is building upon a previous post on how to acquire an anonymous type ... type.

The next question is, how can you cast an arbitrary object into an anonymous type? At a glance this doesn't seem possible as you cannot directly express the type of an anonymous type in code. For instance the following code is not legal.

 Dim o As Object = SomeCall() 
Dim x = Directcast(o, New With {.a = 5})

Even though it's not possible to directly express the type in code, we can indirectly express it via type inference. Anonymous Types are strongly typed in the compiler and it is possible to infer these types where inference is available.

 Public Function CastSpecial(Of T)(ByVal o As Object, ByVal t As T) As T 
    Return DirectCast(o, T)
 End Function

The above function allows us to perform a DirectCast as long as we have an instance of the type we want to cast to. Now we can call the code and passing in the appropriate anonymous type instance.

 Dim o As Object = SomeCall()
 Dim x = CastSpecial(o, New With {.a = 5})

There are a couple of caveats to this approach though.

The actual anonymous type and the one you are casting to must be exactly the same. No polymorphism can be involved.
The anonymous type must be created in the same assembly where you are performing the cast. Anonymous types are specific to the assembly they are created in so performing the cast accross assemblies will cause a InvalidCastException to occur.
It does needlessly create an object to perform the cast.

Singleton Pattern

Jared Parsons — Tue, 04 Sep 2007 20:58:00 GMT

Quite awhile back I posted about how to create a re-usable singleton pattern in .Net. Link is here. A bit of time has passed and I've altered the pattern a bit. The reasons for the change are some new type inference patterns and FxCop cleanliness.

The first pattern I introduced had a couple of FxCop violations. Namely Microsoft.Design CA1000 - Do not declare static members on generic types. The logic here being that static methods don't have any type inference benefits as you must explicitly add the type into the name of the type you were using (in this case Singleton).

Secondly because T was at a class level rather than a method level I couldn't have granualar methods which had differing set of constraints. The result was a pattern that was not always easy to write out.

The new pattern takes care of both of these problems. It has two methods. One of which can be satisfied with a trivial lambda expression. The other can easily be used for classes that satisfy the generic constraint new() with no additional lambda.

    class c1
    {
        public static c1 Instance1 
        {
            get { return Singleton.GetInstance(() => new c1());}
        }

        public static c1 Instance2
        {
            get { return Singleton.GetInstance<c1>(); }
        }

        public c1()
        {

        }
        
    }

Below is the new singleton pattern.

    public delegate T Operation<T>();

    /// <summary>
    /// Used for classes that are single instances per appdomain
    /// </summary>
    public static class Singleton
    {
        private static class Storage<T>
        {
            internal static T s_instance;
        }

        [SuppressMessage("Microsoft.Reliability", "CA2002")]
        public static T GetInstance<T>(Operation<T> op)
        {
            if (Storage<T>.s_instance == null)
            {
                lock (typeof(Storage<T>))
                {
                    if (Storage<T>.s_instance == null)
                    {
                        T temp = op();
                        System.Threading.Thread.MemoryBarrier();
                        Storage<T>.s_instance = temp;
                    }
                }
            }
            return Storage<T>.s_instance;
        }

        public static T GetInstance<T>()
            where T : new()
        {
            return GetInstance(() => new T());
        }
    }

    #endregion
}

Edit: Originally forgot to add the signature for Operation<T>