Consider switching to plain C# types for the data model

[nblumhardt]

Since this lib isn't itself a logging library, and so probably doesn't need to buy into a whole immutable data model, it seems like both perf and usability would be improved by adopting object[], Dictionary<string, object> and plain objects, instead of the ArrayValue, StructureValue and ScalarValue wrappers.

I.e., if I have a deserialized JSON object including a template, it's more likely I've deserialized it into plain collection types than the MessageTemplates data model, and more familiar/simpler to convert into them if I haven't.

Any thoughts on this?

[adamchester]

I’d like to think some more about this...

[SimonCropp]

+1

[SimonCropp]

@adamchester still thinking?

[adamchester]

Sorry for the delay... I think this is a great idea and probably the best default, especially if there was still a sensible way to enable snapshot capturing

[nblumhardt]

👍 yes, snapshotting would still happen the same way as it does now - it's just that the wrapper types would be substituted for their native equivalents. E.g. when an array is logged, we allocate an array within a SequenceValue to snapshot it (and recursively do this to its contents). Under the alternative model, we'd just allocate the new object[] and treat it exactly as we do SequenceValue.

• SequenceValue -> object[]
• StructureValue -> Dictionary<string, object>
• DictionaryValue -> Dictionary<object, object>
• ScalarValue -> the value