Add support for Protobuf RepeatedField collections

[leus]

Protobuf generated entities seem to work well with BuilderGenerator but collections don't get generated. Protobuf collections are of type RepeatedField which are read-only properties that implement IEnumerable.

[leus]

Looking into the code, one could argue that it's worth adding support for read-only collections leveraging something like Add() or AddRange() in the implementation template.

[MelGrubb]

Hmm. The trouble with IEnumerable is that it doesn't have Add or AddRange. You need ICollection to get those. I took a quick glance, though, and it looks like it inherits from IList, which would have those. The more general problem is knowing exactly which type of collection to generate. I'll need to think about that.

[leus]

Yeah, I think you are right supporting IEnumerable is tricky (enumerator functions, backed fields, etc.) but ICollection shouldn't be hard (just use AddRange and forget about it).

[MelGrubb]

Expanding collection support is on my list, but I'm not sure when it'll get done. I think it will require more reflection than what the code is doing now. It will need to be intelligent about whether to just clear the collection or to replace it completely, depending on the properties of the collection itself. What if the class has a settable collection and it's empty. If you've told the builder to put something in the collection, it will have to be smart enough to set it to an appropriate type and then fill it. I like that the library is useful to others, and I'm starting to suspect that it's going to grow into a much larger project than it is. As such, I'm trying to tackle some optimizations first before moving forward. I'll keep this here so that I don't lose track, though.

[MelGrubb]

I've been circling back to try to clear out issues, and at least wanted to add a note here. It should be possible to determine whether a collection can be added to or not based on the semantic model, and perhaps generate Add or AddRange. There is still a problem of ordering though. Properties should never be order-dependent, but in the case of a builder, it would have to know to make sure that the collection is at least initialized before trying to add items to it.

What would you expect to happen if I created a new Foo, added a couple items to its Bar collection, then overwrote Bar entirely, and added a couple more items. Logically, I would expect that everything before the overwrite step would be lost, and that my collection would contain only the new items. Unfortunately, that introduces a whole "timeline" concept to things that might make it harder to use, or at least harder to predict.

I think the only proper solution really is to make it explicitly the responsibility of the person writing the test that uses the builder. Prepare the collection you want the object to have and then set it. My builder pattern is, as I've said, a blueprint, and no object exists until you call Build().

I'm still going to leave this here in case a solution occurs to me in the future, but without introducing a timeline concept to the builders, I can't think of a way to make this work in a clear, predictable way. It seems like it will 100% confuse SOMEONE, so I think it's best to just not try to do this FOR the user.