Hi!

> It's not terribly unreasonable IMO, but before I just writeup the RFC
> as described (jsonRawSerialize taking preceedence over jsonSerialize),
> I thought I'd ask for opinions on the specifics.
> 
> In psuedo-code:
> 
> if (is_object($obj)) {
>   if ($obj implements JsonRawSerializable) {
>     // use $obj->jsonRawSerialize() as is.
>   } elseif ($obj implements JsonSerializble) {
>     // use json_encode($obj->jsonSerialize())
>   } else {
>     // Serialize the object's public properties as a key/value map
>   }
> }

I'm not sure I feel very comfortable with having specialized serialize
interfaces for every format, yet more with having more than one of them.

There's also validation problem - if we don't ensure this is valid JSON,
then whole serialization setup is broken, and who knows which
consequences this will bring.

Also, I'm not sure what is the case for fixed JSON serialization - cases
where the data is completely static and yet you still need to serialize
it is pretty rare IMHO. Yes, we save some cycles on serializing such
things, but how often that happens, really? If it's static, why not just
set it on loading? Maybe I miss some reasonable use case, but so far
sounds pretty exotic to me.


-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to