tags:

views:

87

answers:

3

I want to be able to ask, at run time, an IEnumerable if it is a deferred expression or if it is a concrete collection.

So, if the method was called IsDeferred, then IsDeferred( myList.Where( i => i > 5 ) ) would return true and IsDeferred( myList.Where( i => i > 5 ).ToList() ) would return false.

Thanks.

EDIT:

I thought I would be able to ask this without providing the underlying reason I want to do it, but I guess not. First, as others have pointed out, there is no way to tell this at compile time. The type of a collection cannot necessarily tell you whether it is lazy or not. You can have one IEnumerable which is a deferred query and another which is not (see original question). Using brute force to identify concrete types is not an elegant solution.

Now, as for the reason I want to do this. Imagine a method that takes in an IEnumerable and then references it several times:

public void MyMethod<T>( IEnumerable<T> items) {
  foreach( var item in items )
    // Do stuff.
  Console.WriteLine( "There are " + items.Count() + " items in the collection." );
  if( items.Any() )
    // Do some more things.
}

Now, this looks fine, but if I call MyMethod( myList.Where( i => i.ReallyExpensiveOperation() ) ), then you can see that the expensive Where is going to get executed three times. Once for the iteration, once for the Count, and once more for the Any. I could solve this by making the first line of the MyMethod do a ToList(). But, it would be better if I could not do that if I knew I didn't have to (like, if I knew it was a concrete list already). I understand I could re-write (the completely fake and not at all a real-world example) MyMethod to not reference the items collection multiple times, but I am not interested in that as a solution.

Thanks again.

+4  A: 

it is impossible to create this method for all situations, because only the creator of class knows is it lazy or not. Example: class can be created that prereads values into inner list or not based on some config - you will never to be able to guess. the best you can is to create list of well known types that are certain concrete collections (List, Array, etc.) and check against it. I think that you are working in wrong direction - because "lazyness" of collection should be known at compile time or be configurable (not guessable).

Edit: You can force collection to be eager by calling .ToList (or .ToArray). Call to those methods will force iteration immediately.

Andrey
Lazyness is not known at compile time. You can force a collection from lazy to eager by calling ToList().
Robert Harvey
@Robert Harvey "Lazyness is not known at compile time." this is what my answer about. But last phrase is "or be configurable".
Andrey
+3  A: 

Since Eagerness is up to the implementor, the best you can do is to decide based on the instance's Type.

    public void TypeTest()
    {
        IEnumerable<int> a = Enumerable.Empty<int>();
        IEnumerable<int> b = a.ToList();
        IEnumerable<int> c = b.Where(x => x%2 == 1);

        Console.WriteLine(a.GetType().Name);
        Console.WriteLine(b.GetType().Name);
        Console.WriteLine(c.GetType().Name);
    }

The above code yields these results:

Int32[]
List`1
WhereListIterator`1

Reasonably, one would expect Arrays and types from System.Collections to be be collections. Types with the word Iterator in the name are likely to be lazy. Not all types are so straightforward... for example System.Data.Linq.EntitySet has a property that tells you if it is deferred or not (and the property changes once the EntitySet has been loaded).

You cannot expect to create a complete list of cases, but you might be able to complete enough of a list to accomplish your goal.


I think you're struggling with the blinding glory that is the IEnumerable<T> contract. There are other contracts out there, it sounds like you really need IList<T>. If you used that, the caller would be remiss to hand you a deferred collection.

David B
I think you are spot on about choosing the right interface for your API.
ChaosPandion
+1  A: 

You shouldn't go this way but if you want to try to some heuristics here is a way that cover the basic members of Enumerable and all enumerators generated by yield in the C#4.0 compiler from microsoft :

static readonly Type compilerGeneratedAttributeType = typeof(System.Runtime.CompilerServices.CompilerGeneratedAttribute);

static bool IsDefered(IEnumerable enumerable)
{
    if (enumerable == null) throw new ArgumentNullException("enumerable");

    var type = enumerable.GetType();

    var compilerGenerated = type.GetCustomAttributes(compilerGeneratedAttributeType, false).Length > 0;

    return type.IsNestedPrivate &&
        (
            type.Name.Contains("__") && compilerGenerated
            || type.DeclaringType.Equals(typeof(Enumerable))
        );
}
    }

Please also note that the C# specification say typically not must so even iterator block generated enumerables aren't correctly detected by my sample according to the specification :

An enumerable object is typically an instance of a compiler-generated enumerable class that encapsulates the code in the iterator block and implements the enumerable interfaces, but other methods of implementation are possible. If an enumerable class is generated by the compiler, that class shall be nested, directly or indirectly, in the class containing the function member, it shall have private accessibility, and it shall have a name reserved for compiler use

VirtualBlackFox