Custom serialization for specific classes

[tinoadams]

This is trying to address issues #16. Let me know what you think.

[coveralls]

Coverage increased (+0.2%) to 98.095% when pulling 5c25ea2 on tinoadams:master into 68c6a72 on zumba:master.

[jrbasso]

@tinoadams I tried to work on it in the past for a little bit, but the problem is how to deal with recursions, ie. object A has an attribute with an instance of B. If the JsonSerializer has custom serializers for A and B, how it would work? Besides that, how can we serialize the "native" portion, like regular objects that we have defined in the serializer...

[tinoadams]

@jrbasso I figured that resolving transitive dependencies is responsibility of the custom serializer. In the given example I would expect the custom serializer for class A to return the full structure (nested maps) that must also contain the properties object B ie. array('objA_refToB'=>array('objB_property1'=>'x')) which ultimately becomes {"@type":"A","objA_refToB":{"objB_property1":"x"}}. We have to assume that the custom serializer for class A knows how to serialize all properties of class A including the case where one of the properties contains an instance of class B.

If you see a use case where a custom serializer would want to make use of reflection on some properties then we could expose the serializeData method and pass the current Zumba\JsonSerializer to the custom serialize method. In that case the custom serializer for class A could call serializeData to serialize refToB using reflection ie. return array('objA_refToB'=>$zumbaSerializer->serializeData($objA->refToB)).

Thoughts?

[jrbasso]

@tinoadams This kind matches the behave of Serializable interface, where the serialize method needs to return the desired output. However it doesn't behave like JsonSerializable, which return the non-object value to be serialized (ie, array with fields).

I would argue that following JsonSerializable makes more sense since it is designed for json, like this lib. However, this lib supports JsonSerializable, so the class could potentially implement it. Using the Serializable behavior, like your did, would cover scenarios where the class doesn't implement, like DateTime.

I guess this implementation is a good start to support it. To send the serializer instance to the object can be analyzed it in the future.

Thanks for your contribution!