Ive just opened a new RFC https://wiki.php.net/rfc/jsonserializable regarding Json to Object unserialization.
Hi,
I like the general idea behind that proposal.
I'm not sure how you would want to implement that however (please
expand the rfc on that topic).
Do you want to give the cast syntax a special meaning if used in
connection with json_decode or add the general ability to
cast a stdClass object (as returned by json_decode) to a specific user
type or do you want to change json_decode to return a new class
(extending stdclass) that can be casted in the way you want? The first
two could be considered fundamental changes to the language, the third
may include serious bc concerns.
Wouldn't an additional function (maybe in addition to your proposed
interface; example: json_decode_to(string $json, string $className,
int $options)) solve the issue without changing the language?
Regards,
2015-07-13 15:22 GMT+02:00 Dean Eigenmann dean.eigenmann@icloud.com:
Ive just opened a new RFC https://wiki.php.net/rfc/jsonserializable
regarding Json to Object unserialization.
On Mon, Jul 13, 2015 at 3:22 PM, Dean Eigenmann dean.eigenmann@icloud.com
wrote:
Ive just opened a new RFC https://wiki.php.net/rfc/jsonserializable regarding
Json to Object unserialization.
The approach with typecasting will not work, because the function
json_decode doesn't have that information.
Instead something like the JMS Serializer api is probably necessary: $user
= json_decode($data, 'User');
I agree with Guilherme that we need a second interface for this, especially
because changing the existing one would be a BC break.
I have updated the RFC with a new section showing the updates
Sent from my iPhone
On Mon, Jul 13, 2015 at 3:22 PM, Dean Eigenmann dean.eigenmann@icloud.com
wrote:Ive just opened a new RFC https://wiki.php.net/rfc/jsonserializable regarding
Json to Object unserialization.The approach with typecasting will not work, because the function
json_decode doesn't have that information.Instead something like the JMS Serializer api is probably necessary: $user
= json_decode($data, 'User');I agree with Guilherme that we need a second interface for this, especially
because changing the existing one would be a BC break.
I have updated the RFC with a new section showing the updates
Sent from my iPhone
On Mon, Jul 13, 2015 at 3:22 PM, Dean Eigenmann dean.eigenmann@icloud.com
wrote:Ive just opened a new RFC https://wiki.php.net/rfc/jsonserializable regarding
Json to Object unserialization.The approach with typecasting will not work, because the function
json_decode doesn't have that information.Instead something like the JMS Serializer api is probably necessary: $user
= json_decode($data, 'User');I agree with Guilherme that we need a second interface for this, especially
because changing the existing one would be a BC break.--
What are the advantages of the proposed functionality versus writing a static constructor?
Writing $user = json_decode_to_class($json, User::class); doesn’t seem to offer anything over $user = User::fromJson($json);. In my opinion, it seems less obvious what is happening in the former case and the latter case requires no additional functions or modification to the engine.
Regards,
Aaron
Hi
Ive just opened a new RFC https://wiki.php.net/rfc/jsonserializable
regarding Json to Object unserialization.
As it's been said, the first part (casting) is a no-go. It would have to be
done in a run time by scanning of opcode array which is not nice.
The updated proposal ( json_decode_to_class ) could be implemented with
small modification (missing options param for decoding options) but the
general idea is limited to top level object. It means that you cannot use
it on array of objects or nested objects (properties objects).
This is however something that could be addressed by extended JsonSchema
that I described
internals@lists.php.net/msg78698.html" rel="nofollow" target="_blank">https://www.mail-archive.com/internals@lists.php.net/msg78698.html
As I said before, such implementation will take much more time as I have
got couple of more other things on my list that I want to do on json before
that (sort of prerequisite). It means that the question is if we want an
uncomplete limited solution now or wait slightly longer for a proper
solution. My opinion is that we should wait longer and have a proper
solution.
Cheers
Jakub