Conversation
|
I would avoid using "File" to refer to something that can exist without ever touching disk. Other libraries have gone the route of "Document". I don't see an obvious "better way". I would expect that for Serialize() this encoding data should be provided through the KVSerializerOptions object? Ideally with well-known constants/values rather than BYO-GUID (though that should also be allowed). |
|
KVDocument sounds fine.
This is covered in the kv3 pr: https://github.com/ValveResourceFormat/ValveKeyValue/blob/3a0c305f14cccc19860a64c93ee76da245586099/ValveKeyValue/ValveKeyValue/KeyValues3/Encoding.cs For serializing text files, you wouldn't really need to provide these (default to text encoding in generic format). I'm not sure about adding them to KVSerializerOptions because deserialize gives you a KVDocument that contains these, would make sense for serialize to also take this, which works for generic kv objects, but not the typed variant. EDIT: KV3 will add KVHeader class, so that could be passed into the serializer options, or as an optional argument. |
I made it extend KVObject for backwards compatibility.
KV3 requires a special root object because it has a header that contains format and encoding data. KV2 might have some extra stuff too.
Perhaps there's a better way of doing this?
I think Serialize should have a new overload added to accept this, rather than changing the existing one because this would be a compat break. But how would this work with
Serialize<TData>?