Explain this code previous: Beware of big Task Parallel Library Operations next: Explain this code: Answers Why was something like that created? Comments 04/12/2012 10:33 AM by Justin Lovell Probably to simplify if the two collections are equivalent? Ie: the items in both instances are existing in the two lists? If so, then it begs the question why another comparability method was not manufactured? 04/12/2012 10:33 AM by Justin Lovell Probably to simplify if the two collections are equivalent? Ie: the items in both instances are existing in the two lists? If so, then it begs the question why another comparability method was not manufactured? 04/12/2012 10:39 AM by João Angelo Assuming you're questioning why create Collection if we already have List then I would say the main reason is the one stated in MSDN: "The Collection(T) class provides protected methods that can be used to customize its behavior when adding and removing items, clearing the collection, or setting the value of an existing item." Which allows a custom collection that derives from Collection to have extension points available while a custom collection that derives from List does not. 04/12/2012 10:40 AM by Daniel Grunwald To avoid NullReferenceExceptions - it becomes impossible to pass around null collections (which is rarely useful). default(Collection<T>) probably acts as a read-only empty list. default(Collection<T>) is also usable as a default value for optional parameters, a static field pointing to a read-only list instance isn't. Without such a struct, you need to handle null as a special case whenever you use a list in an optional parameter. 04/12/2012 10:44 AM by giammin because he heard that structs have better performance ;) 04/12/2012 10:46 AM by João Angelo Ignore my previous comment, I assumed that this was referring to the .NET Framework class and not a custom struct. It seems, that at least for me, a picture is not worth a thousand words.... 04/12/2012 10:58 AM by Falhar I/List should be used for intermediate collections inside your code. It is supposed to be fast and non-extensible. I/Collection should be used as class member, when you need to expose collection of items as property. It is also intended for extension, so you have specific behaviour for collection of specific items. The fact, that it has InnerList is implementation detail and should be ignored. 04/12/2012 12:12 PM by Wayne M To allow stupid people to make their own CustomerCollection type classes that inherit, rather than use an IList or ICollection? Not quite sure but it seems to be a NIH thing; I've commonly seen places that will create wrappers for their own collection classes instead of just making it use a built-in type. 04/12/2012 12:21 PM by Indranil It is a much more minimal class than System.Collections.Generic.List. Only implements the IList members. None of the Sort, Search, Reverse methods. Certainly will be easier to test than the full blown List. Possibly a faster implementation can be built? not sure why its a struct though. 04/12/2012 01:19 PM by Matt Davey By making a struct you could potentially create an array of these lists and loop over them using pointer arithmetic, giving you fast jagged array behaviour with the extra functionality of IList... in any case I can't think of a legitimate reason for doing this that isn't solved in other, much nicer ways. 04/12/2012 02:17 PM by Matt Davey One case for a struct like this would be for immutable collections, but the IList interface isn't designed for that... 04/12/2012 02:23 PM by Matt Davey @Wayne M creating first class collections which inherit from generic collection types is not stupid at all. From Object Calisthenics: Rule 4: First class collections Application of this rule is simple: any class that contains a collection should contain no other member variables. Each collection gets wrapped in its own class, so now behaviors related to the collection have a home. You may find that filters become a part of this new class. Also, your new class can handle activities like joining two groups together or applying a rule to each element of the group. 04/12/2012 02:43 PM by Indranil However making it a struct rules out inheritance 04/12/2012 03:34 PM by Winston To create a Proxy if you're not using an ORM or a DynamicProxy. It's a lot of work but, if the guy want to learn from the basics, looks like a good idea. 04/12/2012 04:24 PM by Omer Mor +1 for Daniel Grunwald explanation (structs are non-nullable, can skip null checks) 04/12/2012 05:46 PM by pet http://msdn.microsoft.com/en-us/library/ms182142.aspx 04/12/2012 07:55 PM by João P. Bragança http://stackoverflow.com/questions/945664/can-structs-contain-references-to-reference-types-in-c-sharp/945708#945708 Structs holding references kinda makes them pointless. 04/12/2012 04:49 PM by Martin Doms It's essentially a List decorator that gives optional, changeable ReadOnly behaviour. Not the way I would have implemented it, but I can see the motivation. 04/12/2012 04:52 PM by Martin Doms Of course exposing the inner list negates any advantage the decorator pattern gives, but like I said it's a non-optimal solution to a real problem 04/12/2012 11:39 PM by Google Here's my answer: http://ayende.com/blog/154882/explain-this-code-answers?key=941b81a7-8086-4c45-9406-2ef041ffa711. I'm sure it's ok :) Oren your posts are gooooogled before they are pusblished on your blog... 04/12/2012 11:51 PM by Ayende Rahien What you are seeing is caching differences, the front page is cached for a few minutes, so it is not surprising that you can see this discrepency. 04/13/2012 12:56 AM by Martin Odhelius Since it is a struct it is probably, as Daniel Grunwald already mentioned,probably to avoid NullReferenceExceptions. But since the reason is so vague and can result in both dangerous behavior and dangerous conclusions it should probably not have been created in the first place ;) pet: if you try to get around that warning by just implement your custom implementation of List you probably do not understand why you get the warning in the first place. If you expose the interface rather than the concrete type you can still extend it without doing any custom implementation and still get it extendable. But publicly expose mutable lists are in most situations not a good idea anyway so if you shall expose some sort of collection to the public it would probably be better to expose an IEnumerable 04/13/2012 04:55 AM by Mike Brown Just noticed you're showing the original posted date now. You have a 2 month backlog of posts. I want to be like you when I grow up LOL. Comments have been closed on this topic.