>
> 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.
Same thoughts here. Without further arguments I'd definitely vote against
an RFC suggesting such a change.
Regards, Niklas
