Last post Aug 22, 2013 07:53 PM by TheNutCracker
Aug 22, 2013 06:59 AM|TheNutCracker|LINK
When I hover the two following types in Visual Studio 2012 intellisense reports the following information:
"IEnumerable" type is interface System.Collections.IEnumerable - Exposes the enumerator, which supports a simple iteration over a non-generic collection.
"IEnumerable<T>" type is interface System.Collections.Generic.IEnumerable<out T> - Exposes the enumerator, which supports a simple iteration over a collection of a specified type.
Now, I would interpret the words or phrase 'non-generic' as meaning a 'specific-type'. non-generic meaning specific.
Yet, in the second intellisense report, it states the type is specific as well.
The fact is that we, the programmers, get to enumerate over an IEnumerable without specifying type which I would interpret as a generic collection. The type is known only really to the programmer and not the compiler. If the compiler doesn't know the type(or
doesn't bother to know it) wouldn't that be better described as a 'generic' collection?
The only way I justify these naming conventions is by saying, "Generic means that, the task of defining the type itself for the collection, is left up to me, the programmer, and in that sense, it's generic. So the defintion of the word generic might be expressed
as the compiler saying, "I see your requesting a collection of IEnumerable<T>'s. You tell me what type you wanna use for this collection."
I am viewing these descriptions from my perspective(as a programmer). Maybe Microsoft named them from a different perspective. Im not suggesting any official name changes(or changes to the language) as everything works the way it is. "If it ain't broke,
don't fix it." But the naming bugs me when I think about it, so I thought I would throw this out there for pure discussion to see if I am the only know who just doesn't quite understand the naming conventions for these two types.
Maybe somebody can give me an explanation on how to express the defintion of these types so that it makes just a bit more sense. No big deal. The defintions in intellisense just seem a bit off but I can deal with it.
Aug 22, 2013 07:31 AM|AidyF|LINK
You are confusing the English definition of the word "generic" with the .net framework technology called generics. In .net, generics is the ability to treat types in a "generic" manner, and make the processing code type-agnostic.
IEnumerable<T> is the generic (.net generic) type as it lets us enumerate any type we give it, and the enumeration is type agnostic. If we define IEnumerable<string> we get an enumeration of strings. With IEnumerable<Customer> we get an enumeration of
IEnumerable is non-generic as it does not allow us to give it any type we want at run-time.
If we have .Add for a collection, we have to strongly type the object that can be added in the parameter (eg .Add(1) for an int) but that means that our collection is now, and can only ever be, a collection of ints. If we allow Add to accept an object we
can now Add ints, strings, Customer objects etc....but all to the same collection which is no good. Add is "non generic". However we can Add<T> on List<T> and our collection can still contain any type we want, but it must contain *only* that type, and we
decide the type at run-time. So I can have List<string> and List<int> and those collections are tied to those types. The List itself is type agnostic. That is a "generic type" (.net generic)
Aug 22, 2013 12:03 PM|DMW|LINK
If the compiler doesn't know the type
You honestly believe that the compiler doesn't know the type, in a language which only supports strong typing. (And before you mention dynamic, Anders famously described this as a type that is strongly-typed at being dynamic.)
The compiler fully understands the IEnumerable is, and always will be, working with one specific type: System.Object. Well, to be more precise, it describes a way to get an IEnumerator, which has a Current property that returns System.Object.
So IEnumerable is clearly not generic in any sense, other than it happens that all types in .NET can be treated as System.Object to some extent.
And have you actually tried enumerating over an ArrayList without caring about type. It can be lethal.
On the other hand, when you write a generic type, such as List<T>, you're saying
"Hey, there's a bunch of generic code that I want to use here (i.e. code where I don't care about the type of the object). So compiler dude*, you can fill in the blanks (the type arguments) for me because I want to go out and party, rather than copy and
paste a bunch of stuff."
Now that truly is generic code.
* By compiler dude, I don't necessarily mean the C# compiler. Maybe it's the JIT compiler. After all, the C# compiler's actually pretty pathetic most of the time, just simply translating our code to IL. It's only when it gets dark, and we write "yield return"
or await that it shows its true colours.
Aug 22, 2013 07:53 PM|TheNutCracker|LINK
I like the way you quoted me but only partially. :) The parenthesized portion of my statement would suggest what I really believe.
Thanks for both comments. They are both really good responses. I guess I just tend to look at the situation from the wrong perspective sometimes. There are two different ways of interpreting what the intellisense descriptions of the types mean. You guys
put things in perspective for me. So, thanks for the input.