Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,128 | Comments: 45,550

filter by tags archive


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?

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?

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.

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.


because he heard that structs have better performance ;)

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


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.

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.


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.

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.

Matt Davey

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

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.


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.

Omer Mor

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



João P. Bragança


Structs holding references kinda makes them pointless.

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.

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


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

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.

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

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.

Comment preview

Comments have been closed on this topic.


  1. The worker pattern - one day from now

There are posts all the way to May 30, 2016


  1. The design of RavenDB 4.0 (14):
    26 May 2016 - The client side
  2. RavenDB 3.5 whirl wind tour (14):
    25 May 2016 - Got anything to declare, ya smuggler?
  3. Tasks for the new comer (2):
    15 Apr 2016 - Quartz.NET with RavenDB
  4. Code through the looking glass (5):
    18 Mar 2016 - And a linear search to rule them
  5. Find the bug (8):
    29 Feb 2016 - When you can't rely on your own identity
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats