Ryan, Thanks for the post. Great question. I'm going to answer in-line below.
Is this the intended behavior, or am I missing something? I actually think > this is kind of cool, because the Json.NET's LINQ-to-JSON API is really > cool. I really wish you could do this: > > JObject docObject = doc.ToJObject(); // Or something similar > Yes, it is the "intended" behavior. I use the scare-quotes because really, I'm punted. As a library designer, I try to make as a few decisions for you, the user, as possible. In this case, I didn't want to much about with embedded objects because I have no way of knowing what their original type was, and it's a bit tedious to deal with lots of nested dictionaries. At best, if you, as the user, know that "nestedObject" is a dictionary, you can at least do is something like props["nestedObject"]["name"], but that still is awkward. Instead of using standard generic dictionaries, I could create a custom class with an indexer that would allow for stuff like props["nestedObject.name"]. While that's better, I think most people are just going to want to work with their own domain models. Plus, it would be a lot of work and it's not a typical C# pattern (apart from some data-binding libraries). So, I opted to leave things as is, and let the developer handle those decisions for now. I've discussed this with some other people, and we all feel like it's sort of surprising when you come across this, but is ultimately appreciated. We will be adding a convenience API eventually that will handle deserializing the entire object graph for you, but I expect that to be implemented as extension methods so it wouldn't change any existing behaviors. It would just handle .ToObject<T> for you. That way, if you need to do some special processing during deserialization, you can. It may also require the user use JSON.NET support for JSON-SCHEMA, or something similar. This has to be very well thought out, however, and so we won't be rushing into it. We want it to be as low friction as possible. > So anyway, my main question here is: If I rely on these underlying > Json.NET objects, will they be pulled out from under me at some point in > the future, or is this the way it will stay? > Well, you have a lot of say in this. I'm leaning toward maintaining it as a contract, but ultimately, the community gets a large say in the matter. ;) -- You received this message because you are subscribed to the Google Groups "Couchbase Mobile" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/18e403fd-cb22-4f7b-935f-7902d230acfd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
