Thanks for the answer Rob. I'll go read how these type converters work.
The reason I care about this is that 1) the classes are supposed to be invariant, they're designed this way; 2) XAML is actually a great way to quickly debug your code by dumping out an object graph; I'm projecting binary files into an object graph and want
to verify that the projection is not completely foobar; XAML is actually quite nice in this regard - it's also possible to toss out some data to some folks who can then possibly use XSLT, XLinq and whatnot to do further processing on the data - maybe injecting
it into a SQL store and whatnot - without needing my code (although the code is freely available.)
I guess my reason for disliking the settability requirement is because it forces me to abandon a declarative/functional style of programming. I want to maximize the compiler's (hypothetical) ability to perform optimizations without needing too much analysis
and to have strong guarantees about how the data can be used ("reuse":projection over "use":mutation). This is somewhat a purist stance but it is actually reasonable to not want to have classes have the property of mutability. The WPF freezable properties
is pretty nice but I prefer static guarantees whenever possible; I don't want any code to even try and
attempt to modify the data; or more precisely, I don't want any codepath to have this possibility. I'll admit that these design principles are overkill for the hobby framework I'm building but I believe they are quite sound in general.
It's pretty cool that XAML can project (almost) any object graph to X(A)ML with just one line of code; it's an extremely quick and easy way to generate data, even if for prototyping or analysis purposes.
That being said, you could of course argue that my use-case is silly and I should simply use XLinq projection for this - it's just that this is a use-case XAML could (it appears) easily support with no downsides. I suppose the reasoning behind the design
may also be to help developers in their class design so that they can read in the data again
I wonder if someone should build static analysis for this situation as well and just warn in this case; maybe the Load method should have a type-parameter as well to make it easier to tell, in case the cast doesn't happen right away. Maybe put a "XamlReady"
attribute on the classes.
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.