Ayende @ Rahien

Neil Mosafi commented on Explain this code: Answers

Sun, 22 Apr 2012 20:02:53 GMT

Sure, but I don't think the point of this post is to discuss building a lazy wrapper for a list. I will wait and see cos I'm not sure what it's about now!

Ayende Rahien commented on Explain this code: Answers

Sun, 22 Apr 2012 17:28:19 GMT

Neil, The inner prop will be null, sure. But I can do the lazy init in a single class, not in all places.

Neil Mosafi commented on Explain this code: Answers

Sun, 22 Apr 2012 16:42:12 GMT

But the inner list can be null (and will be) so you gain very little apart from a bit of added indirection and possibly a source of some bugs (every property and method will have to lazy initialise the inner list or something similar). Better to initialise a private readonly field if you want to guarantee non nullness.

Ayende Rahien commented on Explain this code: Answers

Sat, 21 Apr 2012 09:15:58 GMT

Fabian, The idea is that you have a "never null" collection. Don't think just about this scenario, think about how useful it is when you KNOW that a collection can never be null.

Fabian Schmied commented on Explain this code: Answers

Fri, 20 Apr 2012 07:00:15 GMT

@Ayende: I don't understand the purpose, even after your explanation. Are you saying you did this because you needed to define a static field holding an initialized list, but couldn't use a field initializer? If so, why couldn't you use a field initializer?

Clay Ver Valen commented on Explain this code: Answers

Wed, 18 Apr 2012 23:00:13 GMT

You'll have to ensure inner has been initialized before every public method and get_*. Not that you can't, but not very elegant either. Also, make sure to NOT to initialize it to a new instance of "Collection" or you'll get a StackOverflowException. Instead fully qualify it (e.g. System.Collections.ObjectModel.Collection() ) or use List, etc.

Gerke Geurts commented on Explain this code: Answers

Mon, 16 Apr 2012 06:54:21 GMT

Why not be upfront about being immutable and use the following signature instead: public Collection Add(T other)?

Karep commented on Explain this code: Answers

Sat, 14 Apr 2012 21:26:34 GMT

WTF? What i don't understand. What did you get by writing this class? That that you don't have to 'new' Collection?

SergeyT. commented on Explain this code: Answers

Sat, 14 Apr 2012 20:01:30 GMT

@Daniel, @Ayende: actually there is even more subtle way to break this code. Try to add readonly modifier to the "nums" field and run this sample one more time.

Andres commented on Explain this code: Answers

Sat, 14 Apr 2012 19:06:44 GMT

April fools?

Daniel Grunwald commented on Explain this code: Answers

Sat, 14 Apr 2012 10:28:51 GMT

@Ayende Try it, I'm fairly sure your example program will break with an automatic property instead of a field. The actual struct is mutated when the internal list is created on the first Add() call. Your struct behaves like a value type before initialization, and like a reference type after. With an automatic property, there's no way to initialize the underlying field; only the properties' return value gets initialized - so in effect every access to the property returns a new collection.

Ayende Rahien commented on Explain this code: Answers

Sat, 14 Apr 2012 00:16:11 GMT

Daniel, Actually, no, it would still work. The internal list is mutated, not the actual struct.

Scooletz commented on Explain this code: Answers

Fri, 13 Apr 2012 19:34:40 GMT

This code is just wrong. I can imagine a plenty of people reading it and then trying to figure out what's going on. After 15 minutes they would go to the summary of the Collection class, oops! struct and read "Because it allows you to write this sort of code:". Then a facepalm would occur.

Andres commented on Explain this code: Answers

Fri, 13 Apr 2012 15:00:48 GMT

WTF!

Dmitry commented on Explain this code: Answers

Fri, 13 Apr 2012 11:30:40 GMT

Why is it a problem to call the default constructor?

Daniel Grunwald commented on Explain this code: Answers

Fri, 13 Apr 2012 11:05:48 GMT

To elaborate on why such a mutable struct is wrong: Replace your private static field with a static automatic property, and your example program will print 0. (as it mutates the properties' return value, not the actual underlying field) This is a massive pitfall! A NotSupportedException (uninitialized Collection is readonly) would be much better.

Daniel Grunwald commented on Explain this code: Answers

Fri, 13 Apr 2012 11:00:49 GMT

Ouch, so if I copy the struct after it's initialized, the underlying list will be shared, but if I copy it before, then each copy will create its own underlying list? Mutable structs are very bad, especially if they behave like reference types in some aspects, but not in others. To avoid this issue, the default value should be a read-only empty list - so the struct itself will be immutable, only the underlying list (if any) can be modified. That would make the struct act just like a non-nullable reference type on the outside. You'll get an exception when adding to an uninitialized struct, but it still solves the problem of null references for pure read access (which tend to be much more common than write access).

Thomas Levesque commented on Explain this code: Answers

Fri, 13 Apr 2012 09:39:22 GMT

@Mads, yes, this is what I had in mind ;)

Mads Topro commented on Explain this code: Answers

Fri, 13 Apr 2012 09:36:28 GMT

@Thomas: Maybe, Add method is initializing the inner field before use it.

Thomas Levesque commented on Explain this code: Answers

Fri, 13 Apr 2012 09:33:37 GMT

@Richard, it will initialize all fields to their default value, which is null in the case of IList, so you still have to initialize inner when needed (you can't do it in the constructor, since you can't define a default constructor for a struct)

Richard commented on Explain this code: Answers

Fri, 13 Apr 2012 09:22:12 GMT

Structs don't require an initialiser as they always have a constructor that will initialise all its fields. The above code is an abuse of this mechanic.

Buildstarted commented on Explain this code: Answers

Fri, 13 Apr 2012 09:07:38 GMT

The fact that it's missing an initializer for nums?