Rob Relyea said:exoteric said:*snip*@exoteric-
I think I understand your scenarios for XAML:
1) Want immutable types.
- Hope that the immutability part can work with non-default constructors for you.
2) Want to write down most of the state of the object
- What rules would be ideal for you? Some R/O properties (like a parent pointer, get a bit tricky). We use DesignerSerializationVisibilityAttribute to Hide some properties that would normal be written. In your scenario, please review all R/O properties, and see what rules would work for you.
- If you look at http://robrelyea.com/demos/xamlpadsample and the way I write down Pad.config.xaml, you'll see that I'm using XAML for a similar purpose...and it is helpful during development/debugging. I'm also focusing on using that file for config settings, so I'm sticking to normal rules for which properties get written, as I am going to load it later.
Thanks, Rob
My use-case is very simple. I have no private properties and all public properties should be written out - nothing to hide if you will. So you're right, I want to write it all out. Immutable types because they're far easier to reason about. I could imagine cases where it would be required to not write out certain properties but it's a non-issue for my trivial scenario. I'll definitely use the non-default constructor approach now. The below illustrates the motivation further, heh -
The fundamentalist and the minimalist:
"XLinq is superb - what could possibly be better than writing an XLinq query?"
"- Not writing one"
