Open xPaw opened 3 years ago
Pain points from related issues:
var depots = data["Software"]["Valve"]["Steam"]["depots"];
foreach (var depot in (IEnumerable
3. Easy conversion to list. #56 tried this:
```cs
List<KVObject> collection = ((KVCollectionValue)app.Data["config"]["launch"]).children;
which is just awful from a consumer POV, even though it works (with internal
access rights).
(int)value
.Feel free to add more.
I am not sure what we are gaining from having it be immutable.
I'd throw in that null
support is needed for KV3
IMO most of the time we're just reading Valve's stuff, so we don't typically need to mutate it.
Though another way of looking at it would be - if you want immutable types, deserialise it to an immutable type. (We might need to add support for records / init
properties to make this happen.)
What does null
look like in KV3?
Fortunately, records already work. I've added a test for them in ed10cc1.
so we don't typically need to mutate it.
I do sometimes.
What does null look like in KV3?
Literal null
non quoted. I partially support it in my PR by removing the check for non-nullable object value.
Another annoyance I'm running into: KVObject["str"] returns KVValue, but the underlying type is a private KVObjectValue, so I can't cast the KVValue back into KVObject.
And KVObject doesn't extend KVValue, so this seems very inconsistent. This doesn't matter for this[] accessor as it's implemented on both, but if you want to pass around the objects, this gets messy.
Are consumers only ever expected to cast any value into KVValue, but internally we create KVObjectValue with types?
I've been trying to convert VRF to use VKV's types, and it's very painful.