Hi Jens, I put quite a number of hours into this tonight, and ran into several issues. See below:
1. Use of auto-properties for required members with default values:
I had to change the logic in deciding between private field backed property and auto-property for Required members. If we use auto-property, we can't do the field level initialization. Any time we have a default, we need a field backed property.
This undoes a little bit of the work done in bug
THRIFT-1783. What I did was add the field-backed property if a default value was present, but leave out the stuff for _isset when it is required. I am somewhat uncomfortable doing this, though I don't fully understand why the fixing of bug 1783 required removal of the field-backed properties, or the _isset either. Was it just an optimization? Does this sound OK?
2. Required Member Constructor (from bug
THRIFT-1783 creates a constructor taking all required members. Not sure if this is also just a convenience thing, but it also makes the "no-args constructor" required. I would like to get rid of this constructor. It's easy enough to just use object initialization syntax. Is this OK?
3. Set initialization with const value:
For some reason (not sure why, do you?) The type name rendered for Set is not just the .net HashSet<T> but it uses a thrift version called THashSet<T> which does not have a constructor taking IEnumerable<T> like the List<T>, Dictionary<K,V>, and HashSet<T> .net versions do. Therefore my code which initialized the collections defaults fails:
private List<string> _OptListWDef = new List<string>(Constants.CONSTLIST); private Dictionary<string, string> _OptMapWDef = new Dictionary<string, string>(Constants.CONSTMAP); private THashSet<string> _OptSetWDef = new THashSet<string>(Constants.CONSTSET);
If I change the type name from THashSet to HashSet, everything compiles fine. Not sure how you want to handle this.
Let me know about these three things, and I think I can have a patch in to you tomorrow sometime.