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?

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?

Assuming you're questioning why create Collection<T> if we already have List<T> 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<T> to have extension points available while a custom collection that derives from List<T> does not.

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.

because he heard that structs have better performance ;)

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....

I/List<T> should be used for intermediate collections inside your code. It is supposed to be fast and non-extensible. I/Collection<T> 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.

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.

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.

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.

One case for a struct like this would be for immutable collections, but the IList interface isn't designed for that...

@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.

However making it a struct rules out inheritance

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.

+1 for Daniel Grunwald explanation (structs are non-nullable, can skip null checks)

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.

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

http://msdn.microsoft.com/en-us/library/ms182142.aspx

http://stackoverflow.com/questions/945664/can-structs-contain-references-to-reference-types-in-c-sharp/945708#945708

Structs holding references kinda makes them pointless.

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...

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<T>

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.