C# – Why does DataContractJsonSerializer not include generic like JavaScriptSerializer

cwcf

So the JavaScriptSerializer was deprecated in favor of the DataContractJsonSerializer.

var client = new WebClient();
var json = await client.DownloadStringTaskAsync(url); // http://example.com/api/people/1

// Deprecated, but clean looking and generally fits in nicely with 
// other code in my app domain that makes use of generics
var serializer = new JavaScriptSerializer();
Person p = serializer.Deserialize<Person>(json);

// Now have to make use of ugly typeof to get the Type when I 
// already know the Type at compile type. Why no Generic type T?
var serializer = new DataContractJsonSerializer(typeof(Person));
Person p = serializer.ReadObject(json) as Person;

The JavaScriptSerializer is nice and allows you to deserialize using a type of T generic in the function name. Understandably, it's been deprecated for good reason, with the DataContractJsonSerializer, you can decorate your Type to be deserialized with various things so it isn't so brittle like the JavaScriptSerializer, for example

[DataMember(name = "personName")]
public string Name { get; set; }

Is there a particular reason why they decided to only allow users to pass in the Type?

Type type = typeof(Person);

var serializer = new DataContractJsonSerializer(type);
Person p = serializer.ReadObject(json) as Person;

Why not this?

var serializer = new DataContractJsonSerializer();
Person p = serializer.ReadObject<Person>(json);

They can still use reflection with the DataContract decorated attributes based on the T that I've specified on the .ReadObject<T>(json)

Best Answer

JavaScriptSerializer does not seem to be deprecated, based on current MSDN documentation. It was un-obsoleted with .NET 3 SP1 (see the comment from Microsoft). Examples of it's usage also appears in current Microsoft Learning publications.

I'm not sure then if the DataContractJsonSerializer approach is necessarily superior than the other. But of course, some benchmarks might be interesting :)

Related Solutions

C# Language Design – Why ‘void’ is Not Allowed as a Generic Type

The fundamental problem with "void" is that it does not mean the same thing as any other return type. "void" means "if this method returns then it returns no value at all." Not null; null is a value. It returns no value whatsoever.

This really messes up the type system. A type system is essentially a system for making logical deductions about what operations are valid on particular values; a void returning method doesn't return a value, so the question "what operations are valid on this thing?" don't make any sense at all. There's no "thing" for there to be an operation on, valid or invalid.

Moreover, this messes up the runtime something fierce. The .NET runtime is an implementation of the Virtual Execution System, which is specified as a stack machine. That is, a virtual machine where the operations are all characterized in terms of their effect on an evaluation stack. (Of course in practice the machine will be implemented on a machine with both stack and registers, but the virtual execution system assumes just a stack.) The effect of a call to a void method is fundamentally different than the effect of a call to a non-void method; a non-void method always puts something on the stack, which might need to be popped off. A void method never puts something on the stack. And therefore the compiler cannot treat void and non-void methods the same in the case where the method's returned value is ignored; if the method is void then there is no return value so there must be no pop.

For all these reasons, "void" is not a type that can be instantiated; it has no values, that's its whole point. It's not convertible to object, and a void returning method can never, ever be treated polymorphically with a non-void-returning method because doing so corrupts the stack!

Thus, void cannot be used as a type argument, which is a shame, as you note. It would be very convenient.

With the benefit of hindsight, it would have been better for all concerned if instead of nothing whatsoever, a void-returning method automatically returned "Unit", a magical singleton reference type. You would then know that every method call puts something on the stack, you would know that every method call returns something that could be assigned to a variable of object type, and of course Unit could be used as a type argument, so there would be no need to have separate Action and Func delegate types. Sadly, that's not the world we're in.

For some more thoughts in this vein see:

C# – Should web service response use a base class or generic class

The generic response looks effectively clearer, but requires slightly more typing. For example, instead of:

var response = this.GetCar();
if (respose.Success)
{
    Debug.WriteLine(response.Manufacturer);
}

the caller has to write:

var response = this.GetCar();
if (respose.Success && response.Data != null)
{
    Debug.WriteLine(response.Data.Manufacturer);
}

Still, I personally would prefer using generics, since:

It makes it easy to understand what belongs to the protocol, and what is the actual data,
It allows extending or modifying the protocol without carrying for collisions.

Imagine car has Size property. Later, WebResponse should implement Size property to specify the size of the response. Now you have a problem with Car. If data is dynamic, you can't even use your IDE to discover the collisions, and the compiler won't warn you neither.

Also note that according to MSDN, you wouldn't be able to use generics if you want the objects to traverse the boundaries of a context (like in a situation of a sandbox):

The current version of the common language runtime does not support generic ContextBoundObject types or nongeneric ContextBoundObject types that have generic methods.

Best Answer

Related Solutions

C# Language Design – Why ‘void’ is Not Allowed as a Generic Type

C# – Should web service response use a base class or generic class

Related Topic