This project is read-only.

Breaking Changes - Null Lists

Topics: Metadata Model
Apr 29, 2011 at 8:57 PM

I have understand from previous threads that these libraries occasionally introduce breaking changes.  I am curious if there is a way to participate such that we can provide feedback before such changes are introduced.  For example, in Change Set 61083, all of the list properties of the mutable model were changed such that they could be null if there list contents would otherwise be empty.  However, this means that code using these properties must go from:

if (type.Fields.XYZ) 


type.Fields.Add(new FieldDefinition...


if (type.Fields != null && type.Fields.XYZ)


if (type.Fields == null) type.Fields = new List<IFieldDefinition>();

type.Fields.Add(new FieldDefinition...


This is a significant addition of code in the calling libraries, and also is a breaking change that requires a manual review all all code using the mutable model since every reference to a list property must be evaluated since it will not cause a compilation error.  It seems that a safer way to achieve the performance increase without messing up the programming model and breaking code would have been to make the property getter lazy-initialize the list if it is null.

Apr 29, 2011 at 9:22 PM

This is indeed a painful change for all concerned. It was introduced because I can't think of any other way to avoid endless allocation of empty lists while making copies of objects constructed via the mutable object model. This scenario (making copies) now seems more important than it did when I originally designed the mutable object model, making the initial design a bad fit for common usage.

There has been a long standing bug in the issue tracker calling for this change, so it has been in the offing for some time. But ultimately it boils down to a judgement call about the importance of the scenario and the size and impact of the breaking change. One thing this change has going for it is that code broken by it tend to break in obvious and unsubtle ways. An alternative would have been to introduce a whole new mutable model, but that introduces confusion and increases the maintenance burden, so I felt that on the whole it would be better to make the breaking change and get on with things.

So, while I am more than a little mortified at breaking you and I do try very hard not to do it if I have a choice, in this case I have not much else I can offer other than an apology.


Apr 29, 2011 at 9:26 PM
Edited Apr 30, 2011 at 2:14 AM

Understood. On a positive note, after “hopefully” changing about 200 list property interactions in my code, pulling in the latest changes fixed a previous bug I had reported which caused invalid assemblies when mixing .NET 4 and .NET 3.5. I will let you know about the relative performance changes I see as a result of not allocating lists.