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
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
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
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
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