Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:97297 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 46404 invoked from network); 6 Dec 2016 02:12:08 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 6 Dec 2016 02:12:08 -0000 Authentication-Results: pb1.pair.com smtp.mail=yohgaki@ohgaki.net; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=yohgaki@ohgaki.net; sender-id=pass Received-SPF: pass (pb1.pair.com: domain ohgaki.net designates 180.42.98.130 as permitted sender) X-PHP-List-Original-Sender: yohgaki@ohgaki.net X-Host-Fingerprint: 180.42.98.130 ns1.es-i.jp Received: from [180.42.98.130] ([180.42.98.130:54566] helo=es-i.jp) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 47/C8-11772-37E16485 for ; Mon, 05 Dec 2016 21:12:06 -0500 Received: (qmail 87662 invoked by uid 89); 6 Dec 2016 02:11:59 -0000 Received: from unknown (HELO mail-wj0-f174.google.com) (yohgaki@ohgaki.net@209.85.210.174) by 0 with ESMTPA; 6 Dec 2016 02:11:59 -0000 Received: by mail-wj0-f174.google.com with SMTP id tg4so50850508wjb.1 for ; Mon, 05 Dec 2016 18:11:59 -0800 (PST) X-Gm-Message-State: AKaTC00djV/gat+w1BCslSETFFaml0JdgZF4OZcEnUqa+cNkgE9PgFxSACBpk9g1Wa+WtUUsKn1jw5PJx3B9Qw== X-Received: by 10.194.231.8 with SMTP id tc8mr51673809wjc.193.1480990312538; Mon, 05 Dec 2016 18:11:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.38.7 with HTTP; Mon, 5 Dec 2016 18:11:11 -0800 (PST) In-Reply-To: References: Date: Tue, 6 Dec 2016 11:11:11 +0900 X-Gmail-Original-Message-ID: Message-ID: To: Levi Morrison Cc: "internals@lists.php.net" Content-Type: text/plain; charset=UTF-8 Subject: Re: [PHP-DEV] [RFC][VOTE] User defined session serializer From: yohgaki@ohgaki.net (Yasuo Ohgaki) Hi Levi, On Tue, Dec 6, 2016 at 7:50 AM, Levi Morrison wrote: > I apologize for the late review of your RFC. This RFC has a few issues > which I think need to be fixed (yes, this means I am asking you to > pull it out of voting phase). > > It does not specify how to indicate an encoding or decoding error. As > these are unexpected and userland code may throw exceptions anyway I > am fine with an exception being used here (as opposed to returning > null). However in its current form it is incomplete. > > The RFC says this about the return value of the encoding function: > > Returning anything other than string raises E_RECOVERABLE_ERROR > > And similarly this for the decoding function: > > Returning anything other than array raises E_RECOVERABLE_ERROR > > These are not consistent with return type checking. This *must* reuse > the error checking that is already in-place and not provide something > new to accomplish the same thing. What do you mean by inconsistent? Encode function must return "string" for successful operation. Decode function must return "array" for successful operation. Anything other than these return types are invalid and should fail always. Making "false" error condition and treat other invalid types differently? This does not make sense. What do you think missing here? What is your proposal? Thank you. -- Yasuo Ohgaki yohgaki@ohgaki.net