Thanks for the insight. I support leaving it the way it is, because it makes interop with my existing code that relies on Json.NET quite a bit easier. It's definitely tedious to have to pass around things like IList<IDictionary<string, object>> when the object graphs get more complicated.
On Thursday, October 23, 2014 11:52:30 AM UTC-6, Zachary Gramana wrote: > > 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/fee4d42c-e1cf-4ae6-be13-7db8d482b01b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
