Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:87144 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 29296 invoked from network); 13 Jul 2015 14:13:50 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 13 Jul 2015 14:13:50 -0000 Authentication-Results: pb1.pair.com header.from=dean.eigenmann@icloud.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=dean.eigenmann@icloud.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain icloud.com designates 17.158.161.4 as permitted sender) X-PHP-List-Original-Sender: dean.eigenmann@icloud.com X-Host-Fingerprint: 17.158.161.4 nk11p00mm-asmtp005.mac.com Solaris 10 1203 Received: from [17.158.161.4] ([17.158.161.4:42391] helo=nk11p00mm-asmtp005.mac.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 5A/C8-43998-A97C3A55 for ; Mon, 13 Jul 2015 10:13:48 -0400 Received: from nk11p00mm-spool004.mac.com ([17.158.161.119]) by nk11p00mm-asmtp005.mac.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTP id <0NRF00EUQJITGW30@nk11p00mm-asmtp005.mac.com> for internals@lists.php.net; Mon, 13 Jul 2015 14:13:44 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151,1.0.33,0.0.0000 definitions=2015-07-13_09:2015-07-13,2015-07-13,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1507130200 MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_5WTiz59VcGyX4DI6oT3iRQ)" Received: from localhost ([17.158.43.22]) by nk11p00mm-spool004.mac.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTP id <0NRF00AUXJIU5P60@nk11p00mm-spool004.mac.com>; Mon, 13 Jul 2015 14:13:42 +0000 (GMT) To: "Sebastian B.-Hagensen" Cc: internals@lists.php.net Date: Mon, 13 Jul 2015 14:13:42 +0000 (GMT) X-Mailer: iCloud MailClient15D108 MailServer15D87.19522 X-Originating-IP: [91.213.100.10] Message-ID: <59f8fa10-10d2-4498-91a8-bacc3fcab4ed@me.com> Subject: Re: [PHP-DEV] JsonSerializable New Interface method Proposal From: dean.eigenmann@icloud.com (Dean Eigenmann) --Boundary_(ID_5WTiz59VcGyX4DI6oT3iRQ) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT The Additional function you have proposed seems like the easiest and best way to do it currently without changing the language. I was thinking of giving the cast syntax special meaning if used in connection with json_decode, but this would most likely be near to impossible. On Jul 13, 2015, at 04:08 PM, "Sebastian B.-Hagensen" wrote: 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 : Ive just opened a new RFC https://wiki.php.net/rfc/jsonserializable regarding Json to Object unserialization. --Boundary_(ID_5WTiz59VcGyX4DI6oT3iRQ) Content-type: multipart/related; boundary="Boundary_(ID_+qgObwfnSrF0QWGBy3oSjw)"; type="text/html" --Boundary_(ID_+qgObwfnSrF0QWGBy3oSjw) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable
The Additional function you have proposed seems like the easiest and = best way to do it currently without changing the language. I was thinking = of giving the cast syntax special meaning if used in connection with json_= decode, but this would most likely be near to impossible.

On= Jul 13, 2015, at 04:08 PM, "Sebastian B.-Hagensen" <sbj.ml.read@gmail.= com> wrote:

Hi,

I like the general idea behind that= proposal.

I'm not sure how you would want to implement that howeve= r (please
expand the rfc on that topic).
Do you want to give the cas= t syntax a special meaning if used in
connection with json_decode or ad= d the general ability to
cast a stdClass object (as returned by json_de= code) to a specific user
type or do you want to change json_decode to r= eturn a new class
(extending stdclass) that can be casted in the way yo= u want? The first
two could be considered fundamental changes to the la= nguage, the third
may include serious bc concerns.

Wouldn't an a= dditional function (maybe in addition to your proposed
interface; examp= le: json_decode_to(string $json, string $className,
int $options)) solv= e the issue without changing the language?

Regards,


2015= -07-13 15:22 GMT+02:00 Dean Eigenmann <dean.eigen= mann@icloud.com>:
Ive just opened a new RFC https://wiki.php.net/rfc/jsonserializable
regarding Json to Obje= ct unserialization.
= --Boundary_(ID_+qgObwfnSrF0QWGBy3oSjw)-- --Boundary_(ID_5WTiz59VcGyX4DI6oT3iRQ)--