More lenient unmarshal type rules

[jpoehls]

I'm playing with using this package to unmarshal plist files output by the Day One app. They are a bit quirky in that the data types in their plist file change depending on the data. So for example, in one file a value might be <integer> but in another <real>.

I tried to handle this by making my struct fields float64 thinking that the less specific integer should unmarshal into this just fine. Alas, it did not.

list: type mismatch: tried to decode integer into value of type float64

I'd rather not fall back to unmarshalling this as generic XML. Any chance there is a workaround or some change that could be made to your package to support this scenario? Open to any recommendations you have.

[DHowett]

Huh, interesting. You ought to be able to make do with interface{} for the type in question, but I realize that's non-ideal.

Internally, we support the concept of lax decoding - maybe it's useful to enable us to "lax-decode" an int as a float64?

[DHowett]

(also, thank you!)

[DHowett]

Thinking about this more, it makes sense to allow consumers to provide their own plist unmarshaling functions. I'm mulling over a core rewrite (right now, we have an intermediate format to and from which objects are marshaled/unmarshaled before they're flattened out to disk; i'd like to end that :P) that might allow me to integrate something like that.

[DHowett]

The changes in 221fc98 should address this somewhat; you can use a custom unmarshal type.