Sara Golemon
[PHP-DEV] json(Raw)Serializable?
October 24, 2017 02:30AM
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Stanislav Malyshev
Re: [PHP-DEV] json(Raw)Serializable?
October 24, 2017 08:40AM
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Niklas Keller
Re: [PHP-DEV] json(Raw)Serializable?
October 24, 2017 10:50AM
>
> 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
Re: [PHP-DEV] json(Raw)Serializable?
October 24, 2017 04:10PM
On Tue, Oct 24, 2017 at 7:32 AM, Stanislav Malyshev <[email protected]>
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
Re: [PHP-DEV] json(Raw)Serializable?
October 24, 2017 07:20PM
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
Sorry, only registered users may post in this forum.

Click here to login