Reputation: 6699
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.
Upvotes: 2
Views: 371
Reputation: 73243
The correct answer is it is impossible to be 100% correct here but something that works for vast majority of cases would be:
public static bool IsDeferred<T>(this IEnumerable<T> source)
{
switch (source)
{
case ICollection<T> collection:
return false;
case IReadOnlyCollection<T> readOnlyCollection:
return false;
default:
return true;
}
}
You could add more interfaces to it, but the idea is any sane .NET collection should implement at the very least either of the two above interfaces, except of deferred queries. To just blindly materialize your IEnumerables, see this: Is there a way to Memorize or Materialize an IEnumerable? (again something that should work 99% of the times practically speaking)
Upvotes: 0
Reputation: 17837
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
Upvotes: 1
Reputation: 110171
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.
Upvotes: 3
Reputation: 60085
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.
Upvotes: 5