Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87143
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <cbf4eb05-4955-4b47-98cf-0794fb3c13ed@me.com>
References: <cbf4eb05-4955-4b47-98cf-0794fb3c13ed@me.com>
Date: Mon, 13 Jul 2015 16:08:01 +0200
Message-ID: <CAOjCV8yt04oaeWBwFPzdvhupKOeAc+2G2HC1qpxc_2tTG66G_Q@mail.gmail.com>
To: Dean Eigenmann <dean.eigenmann@icloud.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] JsonSerializable New Interface method Proposal
From: sbj.ml.read@gmail.com ("Sebastian B.-Hagensen")

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.