Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » json(Raw)Serializable? »

json(Raw)Serializable?

php.internals

Sara Golemon

8 years ago
https://bugs.php.net/bug.php?id=75400 is asking for a version of JsonSerializable which doesn't involve deserializing/reserialzing round trips when a chunk of JSON is known in advance. 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 } } Perhaps with the stipulation that if jsonRawSerialize() returns null, we'd fallback on jsonSerialize(). Any other non-string results in an encoding error. -Sara

Stas Malyshev

8 years ago
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 smalyshev@gmail.com

Niklas Keller

8 years ago
> > 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

Jakub Zelenka

8 years ago
On Tue, Oct 24, 2017 at 7:32 AM, Stanislav Malyshev <smalyshev@gmail.com> wrote:
> 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. > >
I fully agree with this. In addition to validation we wouldn't be able to assure that options work as well. For example consider options like JSON_HEX_*, JSON_PRETTY_PRINT, JSON_UNESCAPED_SLASHES, JSON_FORCE_OBJECT, JSON_PRESERVE_ZERO_FRACTION, JSON_UNESCAPED_UNICODE and some other encode options. I think this is not a good idea and can cause many problems. So -1 from me. Cheers Jakub

Fleshgrinder

8 years ago
On 10/24/2017 2:20 AM, Sara Golemon wrote:
> https://bugs.php.net/bug.php?id=75400 is asking for a version of > JsonSerializable which doesn't involve deserializing/reserialzing > round trips when a chunk of JSON is known in advance. > > 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 > } > } > > Perhaps with the stipulation that if jsonRawSerialize() returns null, > we'd fallback on jsonSerialize(). Any other non-string results in an > encoding error. > > -Sara >
I agree with the others here. People often think that they can simply write the JSON on their own, but forget about the requirement for valid UTF-8 and other escaping and encoding stuff. It's better to simply not support it in the first place.
-- Richard "Fleshgrinder" Fussenegger