.NET Framework Logic
-
TL;DR is at the bottom if you aren't in for a read.
IList : ICollection
ISet : ICollection
ICollection : IEnumerableOkay, so far so good. IEnumerable can enumerate through a bunch of items, ICollection can modify the items, and List can access the items by index. ISet can also be modified, which is why it inherits ICollection, supports its own set operations, and because it can't be indexed it doesn't inherit IList. Beautiful. Makes sense. As for sensible implementations, we have:
List : IList
Here is where it gets a little wonky:
LinkedList : ICollection
Now I understand that a "linked list" is the common name for the data structure...but if you aren't going to use the world "list" consistently within the same damn namespace, then just change IList to something more descriptive like IIndexedCollection. Now here is where it gets super funky:
Collection : IList
ObservableCollection : Collection
ReadOnlyCollection : IListSooo....if Collection implements IList then why isn't it called something like CustomList? It's purpose is to allow custom implementations to hook into changes to the collection. ObservableCollection has indexed access since Collection actually implements them, so why isn't it ObservableList? Why does ReadOnlyCollection require an IList as input, and why does it provide indexed access? It should be three different types with the following constructors:
ReadOnlyEnumerable(IEnumerable source)
ReadOnlyCollection(ICollection source)
ReadOnlyList(IList source)I just find this all very strange. IQueryable/IEnumerable Side Note: As a related side note, why did they make IQueryable implement IEnumerable? It should be a separate interface with a method ToEnumerable on it which forces query execution. This way, you wouldn't be able to pass an IQueryable into a method that takes IEnumerable and accidentally cause the query to execute, which I see newbies do all the time. They don't realize there's going to be a huge performance problem when the queryable loads all the records from the database and the rest of the filters are executed client side. I don't see why it wouldn't be desirable to explicitly see the point where the IQueryable gets executed and converted to a local IEnumerable. All of my custom IEnumerable extension methods show up on IQueryable objects, and if you i
-
TL;DR is at the bottom if you aren't in for a read.
IList : ICollection
ISet : ICollection
ICollection : IEnumerableOkay, so far so good. IEnumerable can enumerate through a bunch of items, ICollection can modify the items, and List can access the items by index. ISet can also be modified, which is why it inherits ICollection, supports its own set operations, and because it can't be indexed it doesn't inherit IList. Beautiful. Makes sense. As for sensible implementations, we have:
List : IList
Here is where it gets a little wonky:
LinkedList : ICollection
Now I understand that a "linked list" is the common name for the data structure...but if you aren't going to use the world "list" consistently within the same damn namespace, then just change IList to something more descriptive like IIndexedCollection. Now here is where it gets super funky:
Collection : IList
ObservableCollection : Collection
ReadOnlyCollection : IListSooo....if Collection implements IList then why isn't it called something like CustomList? It's purpose is to allow custom implementations to hook into changes to the collection. ObservableCollection has indexed access since Collection actually implements them, so why isn't it ObservableList? Why does ReadOnlyCollection require an IList as input, and why does it provide indexed access? It should be three different types with the following constructors:
ReadOnlyEnumerable(IEnumerable source)
ReadOnlyCollection(ICollection source)
ReadOnlyList(IList source)I just find this all very strange. IQueryable/IEnumerable Side Note: As a related side note, why did they make IQueryable implement IEnumerable? It should be a separate interface with a method ToEnumerable on it which forces query execution. This way, you wouldn't be able to pass an IQueryable into a method that takes IEnumerable and accidentally cause the query to execute, which I see newbies do all the time. They don't realize there's going to be a huge performance problem when the queryable loads all the records from the database and the rest of the filters are executed client side. I don't see why it wouldn't be desirable to explicitly see the point where the IQueryable gets executed and converted to a local IEnumerable. All of my custom IEnumerable extension methods show up on IQueryable objects, and if you i
Probably, because it was developed by a committee - which I suspect have never met - and nobody took any account of what each other was doing. What annoys me is simpler: why does an array have a Length, and a collection a Count?
The universe is composed of electrons, neutrons, protons and......morons. (ThePhantomUpvoter)
-
Probably, because it was developed by a committee - which I suspect have never met - and nobody took any account of what each other was doing. What annoys me is simpler: why does an array have a Length, and a collection a Count?
The universe is composed of electrons, neutrons, protons and......morons. (ThePhantomUpvoter)
I don't mind that one so much. It's splitting hairs and debatable, but Count is more generic than Length. A list can have a longer length than the count of items inside it. A collection could generate values on the fly, so it has no length per se, but rather a count of the values it will spit out. I could see that one from either perspective. I think I'm slightly in favor of consistency and keeping it Length but whatever.
-
Probably, because it was developed by a committee - which I suspect have never met - and nobody took any account of what each other was doing. What annoys me is simpler: why does an array have a Length, and a collection a Count?
The universe is composed of electrons, neutrons, protons and......morons. (ThePhantomUpvoter)
Here is a better worded explanation than I just offered you: http://stackoverflow.com/questions/300522/count-vs-length-vs-size-in-a-collection/300540[^]
-
Probably, because it was developed by a committee - which I suspect have never met - and nobody took any account of what each other was doing. What annoys me is simpler: why does an array have a Length, and a collection a Count?
The universe is composed of electrons, neutrons, protons and......morons. (ThePhantomUpvoter)
-
TL;DR is at the bottom if you aren't in for a read.
IList : ICollection
ISet : ICollection
ICollection : IEnumerableOkay, so far so good. IEnumerable can enumerate through a bunch of items, ICollection can modify the items, and List can access the items by index. ISet can also be modified, which is why it inherits ICollection, supports its own set operations, and because it can't be indexed it doesn't inherit IList. Beautiful. Makes sense. As for sensible implementations, we have:
List : IList
Here is where it gets a little wonky:
LinkedList : ICollection
Now I understand that a "linked list" is the common name for the data structure...but if you aren't going to use the world "list" consistently within the same damn namespace, then just change IList to something more descriptive like IIndexedCollection. Now here is where it gets super funky:
Collection : IList
ObservableCollection : Collection
ReadOnlyCollection : IListSooo....if Collection implements IList then why isn't it called something like CustomList? It's purpose is to allow custom implementations to hook into changes to the collection. ObservableCollection has indexed access since Collection actually implements them, so why isn't it ObservableList? Why does ReadOnlyCollection require an IList as input, and why does it provide indexed access? It should be three different types with the following constructors:
ReadOnlyEnumerable(IEnumerable source)
ReadOnlyCollection(ICollection source)
ReadOnlyList(IList source)I just find this all very strange. IQueryable/IEnumerable Side Note: As a related side note, why did they make IQueryable implement IEnumerable? It should be a separate interface with a method ToEnumerable on it which forces query execution. This way, you wouldn't be able to pass an IQueryable into a method that takes IEnumerable and accidentally cause the query to execute, which I see newbies do all the time. They don't realize there's going to be a huge performance problem when the queryable loads all the records from the database and the rest of the filters are executed client side. I don't see why it wouldn't be desirable to explicitly see the point where the IQueryable gets executed and converted to a local IEnumerable. All of my custom IEnumerable extension methods show up on IQueryable objects, and if you i
My favourite, of those I've randomly stumbled into, is the donkey who decided that it would be smart to index arrays as (row, column) and DataGridViews as (column, row). That had me editing a custom IEnumerable for ages before I finally checked the DGV syntax. Could. Not. Believe. It.
-
Probably, because it was developed by a committee - which I suspect have never met - and nobody took any account of what each other was doing. What annoys me is simpler: why does an array have a Length, and a collection a Count?
The universe is composed of electrons, neutrons, protons and......morons. (ThePhantomUpvoter)
OriginalGriff wrote:
why does an array have a Length, and a collection a Count?
An array is a contiguous block of memory having a specific allocation length, whereas a collection is a "bag" of items having a count. At least, that's how I always think about it. :) Marc
Testers Wanted!
Latest Article: User Authentication on Ruby on Rails - the definitive how to
My Blog -
TL;DR is at the bottom if you aren't in for a read.
IList : ICollection
ISet : ICollection
ICollection : IEnumerableOkay, so far so good. IEnumerable can enumerate through a bunch of items, ICollection can modify the items, and List can access the items by index. ISet can also be modified, which is why it inherits ICollection, supports its own set operations, and because it can't be indexed it doesn't inherit IList. Beautiful. Makes sense. As for sensible implementations, we have:
List : IList
Here is where it gets a little wonky:
LinkedList : ICollection
Now I understand that a "linked list" is the common name for the data structure...but if you aren't going to use the world "list" consistently within the same damn namespace, then just change IList to something more descriptive like IIndexedCollection. Now here is where it gets super funky:
Collection : IList
ObservableCollection : Collection
ReadOnlyCollection : IListSooo....if Collection implements IList then why isn't it called something like CustomList? It's purpose is to allow custom implementations to hook into changes to the collection. ObservableCollection has indexed access since Collection actually implements them, so why isn't it ObservableList? Why does ReadOnlyCollection require an IList as input, and why does it provide indexed access? It should be three different types with the following constructors:
ReadOnlyEnumerable(IEnumerable source)
ReadOnlyCollection(ICollection source)
ReadOnlyList(IList source)I just find this all very strange. IQueryable/IEnumerable Side Note: As a related side note, why did they make IQueryable implement IEnumerable? It should be a separate interface with a method ToEnumerable on it which forces query execution. This way, you wouldn't be able to pass an IQueryable into a method that takes IEnumerable and accidentally cause the query to execute, which I see newbies do all the time. They don't realize there's going to be a huge performance problem when the queryable loads all the records from the database and the rest of the filters are executed client side. I don't see why it wouldn't be desirable to explicitly see the point where the IQueryable gets executed and converted to a local IEnumerable. All of my custom IEnumerable extension methods show up on IQueryable objects, and if you i
You are right - it was too long to read (ie. size and length were both too long; I counted my time carefully). Strings are also a special case where they have both a size and a length.
char buff[] = "Hello";
int iSize = sizeof(buff); // 6
int iLen = strlen(buff); // 5-- Harvey
-
TL;DR is at the bottom if you aren't in for a read.
IList : ICollection
ISet : ICollection
ICollection : IEnumerableOkay, so far so good. IEnumerable can enumerate through a bunch of items, ICollection can modify the items, and List can access the items by index. ISet can also be modified, which is why it inherits ICollection, supports its own set operations, and because it can't be indexed it doesn't inherit IList. Beautiful. Makes sense. As for sensible implementations, we have:
List : IList
Here is where it gets a little wonky:
LinkedList : ICollection
Now I understand that a "linked list" is the common name for the data structure...but if you aren't going to use the world "list" consistently within the same damn namespace, then just change IList to something more descriptive like IIndexedCollection. Now here is where it gets super funky:
Collection : IList
ObservableCollection : Collection
ReadOnlyCollection : IListSooo....if Collection implements IList then why isn't it called something like CustomList? It's purpose is to allow custom implementations to hook into changes to the collection. ObservableCollection has indexed access since Collection actually implements them, so why isn't it ObservableList? Why does ReadOnlyCollection require an IList as input, and why does it provide indexed access? It should be three different types with the following constructors:
ReadOnlyEnumerable(IEnumerable source)
ReadOnlyCollection(ICollection source)
ReadOnlyList(IList source)I just find this all very strange. IQueryable/IEnumerable Side Note: As a related side note, why did they make IQueryable implement IEnumerable? It should be a separate interface with a method ToEnumerable on it which forces query execution. This way, you wouldn't be able to pass an IQueryable into a method that takes IEnumerable and accidentally cause the query to execute, which I see newbies do all the time. They don't realize there's going to be a huge performance problem when the queryable loads all the records from the database and the rest of the filters are executed client side. I don't see why it wouldn't be desirable to explicitly see the point where the IQueryable gets executed and converted to a local IEnumerable. All of my custom IEnumerable extension methods show up on IQueryable objects, and if you i
Mike Marynowski wrote:
I just find this all very strange.
Although much of the time naming is fairly easy that isn't always the case. And it becomes more problematic with more esoteric designs, with multiple inheritance possibilities (primarily interfaces) and with multiple developers.
-
TL;DR is at the bottom if you aren't in for a read.
IList : ICollection
ISet : ICollection
ICollection : IEnumerableOkay, so far so good. IEnumerable can enumerate through a bunch of items, ICollection can modify the items, and List can access the items by index. ISet can also be modified, which is why it inherits ICollection, supports its own set operations, and because it can't be indexed it doesn't inherit IList. Beautiful. Makes sense. As for sensible implementations, we have:
List : IList
Here is where it gets a little wonky:
LinkedList : ICollection
Now I understand that a "linked list" is the common name for the data structure...but if you aren't going to use the world "list" consistently within the same damn namespace, then just change IList to something more descriptive like IIndexedCollection. Now here is where it gets super funky:
Collection : IList
ObservableCollection : Collection
ReadOnlyCollection : IListSooo....if Collection implements IList then why isn't it called something like CustomList? It's purpose is to allow custom implementations to hook into changes to the collection. ObservableCollection has indexed access since Collection actually implements them, so why isn't it ObservableList? Why does ReadOnlyCollection require an IList as input, and why does it provide indexed access? It should be three different types with the following constructors:
ReadOnlyEnumerable(IEnumerable source)
ReadOnlyCollection(ICollection source)
ReadOnlyList(IList source)I just find this all very strange. IQueryable/IEnumerable Side Note: As a related side note, why did they make IQueryable implement IEnumerable? It should be a separate interface with a method ToEnumerable on it which forces query execution. This way, you wouldn't be able to pass an IQueryable into a method that takes IEnumerable and accidentally cause the query to execute, which I see newbies do all the time. They don't realize there's going to be a huge performance problem when the queryable loads all the records from the database and the rest of the filters are executed client side. I don't see why it wouldn't be desirable to explicitly see the point where the IQueryable gets executed and converted to a local IEnumerable. All of my custom IEnumerable extension methods show up on IQueryable objects, and if you i
Enjoyed reading your post. :-)
Regards, Nish
Blog: voidnish.wordpress.com The life of a Malayalee American - by Nish
An article I recently wrote for an event souvenir
-
TL;DR is at the bottom if you aren't in for a read.
IList : ICollection
ISet : ICollection
ICollection : IEnumerableOkay, so far so good. IEnumerable can enumerate through a bunch of items, ICollection can modify the items, and List can access the items by index. ISet can also be modified, which is why it inherits ICollection, supports its own set operations, and because it can't be indexed it doesn't inherit IList. Beautiful. Makes sense. As for sensible implementations, we have:
List : IList
Here is where it gets a little wonky:
LinkedList : ICollection
Now I understand that a "linked list" is the common name for the data structure...but if you aren't going to use the world "list" consistently within the same damn namespace, then just change IList to something more descriptive like IIndexedCollection. Now here is where it gets super funky:
Collection : IList
ObservableCollection : Collection
ReadOnlyCollection : IListSooo....if Collection implements IList then why isn't it called something like CustomList? It's purpose is to allow custom implementations to hook into changes to the collection. ObservableCollection has indexed access since Collection actually implements them, so why isn't it ObservableList? Why does ReadOnlyCollection require an IList as input, and why does it provide indexed access? It should be three different types with the following constructors:
ReadOnlyEnumerable(IEnumerable source)
ReadOnlyCollection(ICollection source)
ReadOnlyList(IList source)I just find this all very strange. IQueryable/IEnumerable Side Note: As a related side note, why did they make IQueryable implement IEnumerable? It should be a separate interface with a method ToEnumerable on it which forces query execution. This way, you wouldn't be able to pass an IQueryable into a method that takes IEnumerable and accidentally cause the query to execute, which I see newbies do all the time. They don't realize there's going to be a huge performance problem when the queryable loads all the records from the database and the rest of the filters are executed client side. I don't see why it wouldn't be desirable to explicitly see the point where the IQueryable gets executed and converted to a local IEnumerable. All of my custom IEnumerable extension methods show up on IQueryable objects, and if you i
An excellent example of a post, that, if posted in the C#, or .NET FrameWork forum, might have led to an even more educational discussion. yours, Bill
“Human beings do not live in the objective world alone, nor alone in the world of social activity as ordinarily understood, but are very much at the mercy of the particular language which has become the medium of expression for their society. It is quite an illusion to imagine that one adjusts to reality essentially without the use of language and that language is merely an incidental means of solving specific problems of communication or reflection." Edward Sapir, 1929
-
TL;DR is at the bottom if you aren't in for a read.
IList : ICollection
ISet : ICollection
ICollection : IEnumerableOkay, so far so good. IEnumerable can enumerate through a bunch of items, ICollection can modify the items, and List can access the items by index. ISet can also be modified, which is why it inherits ICollection, supports its own set operations, and because it can't be indexed it doesn't inherit IList. Beautiful. Makes sense. As for sensible implementations, we have:
List : IList
Here is where it gets a little wonky:
LinkedList : ICollection
Now I understand that a "linked list" is the common name for the data structure...but if you aren't going to use the world "list" consistently within the same damn namespace, then just change IList to something more descriptive like IIndexedCollection. Now here is where it gets super funky:
Collection : IList
ObservableCollection : Collection
ReadOnlyCollection : IListSooo....if Collection implements IList then why isn't it called something like CustomList? It's purpose is to allow custom implementations to hook into changes to the collection. ObservableCollection has indexed access since Collection actually implements them, so why isn't it ObservableList? Why does ReadOnlyCollection require an IList as input, and why does it provide indexed access? It should be three different types with the following constructors:
ReadOnlyEnumerable(IEnumerable source)
ReadOnlyCollection(ICollection source)
ReadOnlyList(IList source)I just find this all very strange. IQueryable/IEnumerable Side Note: As a related side note, why did they make IQueryable implement IEnumerable? It should be a separate interface with a method ToEnumerable on it which forces query execution. This way, you wouldn't be able to pass an IQueryable into a method that takes IEnumerable and accidentally cause the query to execute, which I see newbies do all the time. They don't realize there's going to be a huge performance problem when the queryable loads all the records from the database and the rest of the filters are executed client side. I don't see why it wouldn't be desirable to explicitly see the point where the IQueryable gets executed and converted to a local IEnumerable. All of my custom IEnumerable extension methods show up on IQueryable objects, and if you i
Logic? Microsoft? Does not compute!
Gryphons Are Awesome! Gryphons Are Awesome!
-
TL;DR is at the bottom if you aren't in for a read.
IList : ICollection
ISet : ICollection
ICollection : IEnumerableOkay, so far so good. IEnumerable can enumerate through a bunch of items, ICollection can modify the items, and List can access the items by index. ISet can also be modified, which is why it inherits ICollection, supports its own set operations, and because it can't be indexed it doesn't inherit IList. Beautiful. Makes sense. As for sensible implementations, we have:
List : IList
Here is where it gets a little wonky:
LinkedList : ICollection
Now I understand that a "linked list" is the common name for the data structure...but if you aren't going to use the world "list" consistently within the same damn namespace, then just change IList to something more descriptive like IIndexedCollection. Now here is where it gets super funky:
Collection : IList
ObservableCollection : Collection
ReadOnlyCollection : IListSooo....if Collection implements IList then why isn't it called something like CustomList? It's purpose is to allow custom implementations to hook into changes to the collection. ObservableCollection has indexed access since Collection actually implements them, so why isn't it ObservableList? Why does ReadOnlyCollection require an IList as input, and why does it provide indexed access? It should be three different types with the following constructors:
ReadOnlyEnumerable(IEnumerable source)
ReadOnlyCollection(ICollection source)
ReadOnlyList(IList source)I just find this all very strange. IQueryable/IEnumerable Side Note: As a related side note, why did they make IQueryable implement IEnumerable? It should be a separate interface with a method ToEnumerable on it which forces query execution. This way, you wouldn't be able to pass an IQueryable into a method that takes IEnumerable and accidentally cause the query to execute, which I see newbies do all the time. They don't realize there's going to be a huge performance problem when the queryable loads all the records from the database and the rest of the filters are executed client side. I don't see why it wouldn't be desirable to explicitly see the point where the IQueryable gets executed and converted to a local IEnumerable. All of my custom IEnumerable extension methods show up on IQueryable objects, and if you i
Don't take consistency too seriously, or you would end up totally bald... ;P
CEO at: - Rafaga Systems - Para Facturas - Modern Components for the moment...
