Ayende @ Rahien

Mike Brown commented on Explain this code

Fri, 13 Apr 2012 04:55:18 GMT

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.

Martin Odhelius commented on Explain this code

Fri, 13 Apr 2012 00:56:52 GMT

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

Ayende Rahien commented on Explain this code

Thu, 12 Apr 2012 23:51:30 GMT

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.

Google commented on Explain this code

Thu, 12 Apr 2012 23:39:46 GMT

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

João P. Bragança commented on Explain this code

Thu, 12 Apr 2012 19:55:18 GMT

http://stackoverflow.com/questions/945664/can-structs-contain-references-to-reference-types-in-c-sharp/945708#945708 Structs holding references kinda makes them pointless.

pet commented on Explain this code

Thu, 12 Apr 2012 17:46:16 GMT

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

Martin Doms commented on Explain this code

Thu, 12 Apr 2012 16:52:54 GMT

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

Martin Doms commented on Explain this code

Thu, 12 Apr 2012 16:49:12 GMT

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.

Omer Mor commented on Explain this code

Thu, 12 Apr 2012 16:24:21 GMT

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

Winston commented on Explain this code

Thu, 12 Apr 2012 15:34:57 GMT

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.

Indranil commented on Explain this code

Thu, 12 Apr 2012 14:43:54 GMT

However making it a struct rules out inheritance

Matt Davey commented on Explain this code

Thu, 12 Apr 2012 14:23:34 GMT

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

Matt Davey commented on Explain this code

Thu, 12 Apr 2012 14:17:13 GMT

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

Matt Davey commented on Explain this code

Thu, 12 Apr 2012 13:19:42 GMT

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.

Indranil commented on Explain this code

Thu, 12 Apr 2012 12:21:05 GMT

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.

Wayne M commented on Explain this code

Thu, 12 Apr 2012 12:12:36 GMT

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.

Falhar commented on Explain this code

Thu, 12 Apr 2012 10:58:30 GMT

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.

João Angelo commented on Explain this code

Thu, 12 Apr 2012 10:46:04 GMT

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

giammin commented on Explain this code

Thu, 12 Apr 2012 10:44:38 GMT

because he heard that structs have better performance ;)

Daniel Grunwald commented on Explain this code

Thu, 12 Apr 2012 10:40:07 GMT

To avoid NullReferenceExceptions - it becomes impossible to pass around null collections (which is rarely useful). `default(Collection)` probably acts as a read-only empty list. `default(Collection)` 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.

João Angelo commented on Explain this code

Thu, 12 Apr 2012 10:39:28 GMT

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.

Justin Lovell commented on Explain this code

Thu, 12 Apr 2012 10:33:55 GMT

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 commented on Explain this code

Thu, 12 Apr 2012 10:33:36 GMT