Made ParseClient.ConvertTo() a public API.

[richardjrossiii]

ConvertTo's functionality is useful for external developers if they ever have to deal with CloudCode, or coercing other types return from the SDK.

Fixes #67.

[hallucinogen]

I'm totally OK with this and this is something that currently only exists in .NET SDK. Question for the other team members:

1. What do you think about opening this up?
2. Does it make sense to implement this in other SDKs?
   @grantland @nlutsenko @wangmengyan95 @andrewimm

[nlutsenko]

iOS/OSX/watchOS/tvOS - simply type casting works great.
Don't feel strongly, but can see that this is valuable.
The only thing that comes to my mind - does it make sense to leave on ParseClient or rather it would be better to move it to something like Parse on .NET`?

[grantland]

Don't we already convert known datatypes? https://github.com/ParsePlatform/Parse-SDK-Android/blob/master/Parse/src/main/java/com/parse/ParseCloudCodeController.java#L45

We don't really allow deserializing from user JSON since odd things can happen, so I'm really wary of this.

Lastly, +1 to it oddly being on ParseClient

[wangmengyan95]

Don't feel strongly too. +1 for move it in to Parse. I want to know what odd things can happen when we deserializing from user JSON, any ideas? @richardjrossiii @nlutsenko @hallucinogen

[grantland]

What's the problem we're solving here? ParseCloud should be returning decoded responses.

[richardjrossiii]

@grantland We're solving an issue with .NET's generic type system. When we decode from the server, we give back a dictionary of type Dictionary<string, object>. In .NET's type system, we do not have any way to treat that as a dictionary of type Dictionary<string, ParseObject>, as the two are separate types at run-time (generics are not type-erased as in java).

This becomes more useful as you get a deeper nested structure, as at each level you'll be dealing with either Dictionary<string, object> or List<Object>, and if you wish to grab any of those collections as another type, You're pretty much SOL.

Also, we don't have a Parse class on .NET. If we did, there would be a naming conflict between the Parse class and the Parse namespace, which is why we use ParseClient class.

[wangmengyan95]

@richardjrossiii, thanks for the clarification. I am OK with this change on .NET. But probably we do not need this in Android.

[richardjrossiii]

Hey guys, I just updated the PR to move the utility into the Parse.Utilities namespace, under the invocation Conversion.As<T>(value). Let me know your thoughts.

[hallucinogen]

I forgot the end result of our discussion. Do we want this to be public or just want to separate this out and mark as "pending decision whether we want to make it public/make it separate .dll or do nothing and leave it here"?

[richardjrossiii]

I think we want it public for now, if we decide to do it as a separate project/repository, we'll make it a dependency, and it would stay under the same namespace.

[hallucinogen]

Sounds good!

[hallucinogen]

I like the direction we're going here. Several cleanup and one major question.

[richardjrossiii]

I think I addressed all of your comments in various replies, but I forgot to pass it back. Whoops.