Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:87866 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 27446 invoked from network); 22 Aug 2015 15:55:24 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 22 Aug 2015 15:55:24 -0000 Authentication-Results: pb1.pair.com smtp.mail=ircmaxell@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=ircmaxell@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.173 as permitted sender) X-PHP-List-Original-Sender: ircmaxell@gmail.com X-Host-Fingerprint: 209.85.217.173 mail-lb0-f173.google.com Received: from [209.85.217.173] ([209.85.217.173:34765] helo=mail-lb0-f173.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id C6/D1-06657-A6B98D55 for ; Sat, 22 Aug 2015 11:55:23 -0400 Received: by lbbtg9 with SMTP id tg9so59294928lbb.1 for ; Sat, 22 Aug 2015 08:55:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=U20Hyu/h1EX/yd0CIZxkh0mZvGl2TAYeFoxFpt5P2Q8=; b=E6jgZx+fLSkoUKS0S9vbe4XzUnoM2FNWUQlktXVoKSpOw0MHLYFYmaUVb6aHqy/41g IXHOUfXGA1PBngge/SJq8+ooL84KmpU18vo6ulBpO+F7dbFNQbuCTO17cvCPJ2Fn1t/t HHFIOIh6njA0EcOaN8dchJjxCruspmpg+5PWqFemCtOm3Tb8ssYIQXyEZ4f0uLdTw+I9 cCP3eU9P88DezZ4diU9JXjvtGw37CwM1YfTVfbaYJx/Qx2OXKIvkMQdZwh6POUdxVRhy OwTouLyKgBG9abzQrB8s09NoKiizyin289FOjsg64BbTpKbDbx2ohubyJLrAsXCgxuMs TvjA== MIME-Version: 1.0 X-Received: by 10.112.158.70 with SMTP id ws6mr13051265lbb.28.1440258919938; Sat, 22 Aug 2015 08:55:19 -0700 (PDT) Received: by 10.25.141.131 with HTTP; Sat, 22 Aug 2015 08:55:19 -0700 (PDT) In-Reply-To: <04aa01d0dce7$9e16e100$da44a300$@belski.net> References: <99CE9AAF-E6E9-4D37-B462-E4A63139EAFB@icicle.io> <03af01d0dc6e$fe3a20c0$faae6240$@belski.net> <04aa01d0dce7$9e16e100$da44a300$@belski.net> Date: Sat, 22 Aug 2015 11:55:19 -0400 Message-ID: To: Anatol Belski Cc: Pierre Joye , Scott Arciszewski , Niklas Keller , Trevor Suarez , PHP internals Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7 From: ircmaxell@gmail.com (Anthony Ferrara) Anatol, On Sat, Aug 22, 2015 at 10:34 AM, Anatol Belski wro= te: > Hi Anthony, > >> -----Original Message----- >> From: Anthony Ferrara [mailto:ircmaxell@gmail.com] >> Sent: Saturday, August 22, 2015 4:44 AM >> To: Pierre Joye >> Cc: Anatol Belski ; Scott Arciszewski >> ; Niklas Keller ; Trevor Suarez >> ; PHP internals >> Subject: Re: [PHP-DEV] Recap - Core functions throwing exceptions in PHP= 7 >> >> Pierre >> >> On Aug 21, 2015 22:33, "Pierre Joye" wrote: >> > >> > On Sat, Aug 22, 2015 at 9:16 AM, Anthony Ferrara >> wrote: >> > >> > > If that's what it will take I will happily draft one tomorrow mornin= g. >> But >> > > if the RMs are against it, I will respect that as well. Hence the >> dilemma. >> > >> > For what I understand the RMs are not against what it is proposed but >> > its incompleteness and the fact that it affects the timeline for php >> > 7. >> > >> > The sooner will benefit from a RFC, making this whole discussion a lot >> > clearer. The latter is a requirement to change, even slightly, >> > anything about what we decided for php 7. The RMs role is to ensure we >> > respect what we decided by RFC, hence the oppositions. >> >> By convention, it is also to decide which rfcs are applicable for a spec= ific release. >> I would like to respect that. If they say no, I won't waste time and ene= rgy on the >> rfc process as it will be pointless as it won't affect 7.0. If they say = yes, then we >> can make it quick and as painless as possible and settle it once and for= all. >> >> It bothers me though that it has to come down to this. But that's anothe= r >> discussion for another day. >> > Thanks for your constructive responses and deferential conduct. > > Looking retrospectively t the RFC votes closing days noted in the wiki > > - engine exceptions on March 8th > - CSPRNG on March 28th > - Throwable on June 17th > > the engine exceptions and CSPRNG lay quite near in time, so it is obvious= CSPRNG implementation couldn't have been changed short before or after the= other one as they cross each other so close in time. A notable fact also i= s that quite a new stuff in Throwable was taken already after release circl= e start and the point of no accept for the new RFCs. In any case, by the ti= mes so much of new functionality was clearly overmuch to digest. And it is = still even more of discovery for people not having PHP7 experiences. > > For what it matters, a suggestion about a need on a strategy with this ma= tter sounded in the early days of this discussion. Unfortunately it was not= taken seriously, which is sad as well. The exact goal of calling for RFC a= lready at that time was to bring all the bike shedding onto a productive pa= th and to avoid a situation like it is now. Actually this argument is nothi= ng else than bike shedding on the times and mindsets, so were not worth to = mention. But having not the 1.5 month time lost, we probably wouldn't stand= where we stand now. > > From what all the bike shedding crystalized, there are at least three mai= n directions to see, when it comes to throw in functions. Please correct me= when I'm wrong > > - security aspect (this discussion) > - conversion of fatal errors (touched partially in a PR by Aaron) > - ZPP handling (mentioned by Nikita) > > These look like they can be handled separately, what they have in common = is > > - definition of Error and Exception use case > - further development of the exception hierarchy > > Please don't catch me on the above, it is only what could be marked by my= mind from the discussions. > > From these, either there can be an RFC with a proper solution of one or a= ll the topics spliced with the possible delay of the PHP7 final awareness, = or there can be an RFC to include a partial solution being pushed so far an= d possible inconsistency consequences, or CSPRNG functionality can be defer= red until a complete solution, or CSPRNG can be reimplemented as class wher= e exceptions belong to the natural flow, or a good sustainable solution can= be offered in 7.1. Any other ideas. From the time line - there are five re= lease slots until final yet. Were it an RFC which is accepted, the change w= ould land in RC3 most likely, that would mean there were yet three release = slots till final. Under the condition that the current timeline is held. > > From the last stand point discussed with the other RMs, as they seem not = to be reachable for a direct discussion most of today - such a change affec= ts long term features and language paradigm, which is the matter of the com= munity competence. There's the 7.0 timeline which is a voted thing, there i= s a release process document which defines that the votes take place on RFC= s directly and not on the mailing lists. The RMs belief is that the suggest= ed change is the exact kind of needing a collective decision. Due to the co= ncerns explained earlier, the timeline RFC and other items seem to be in cl= ash with the change how it is proposed ATM. To undo/change any of those ite= ms to pass the suggested change in, another RFC seems to be inevitable. Wit= h the hope that the cautions expressed were taken into account it's up to e= veryone to take actions and make a choice they hold for right. > > Anthony, sincere thanks for your activity and open minded handling in thi= s affair. From what it sounds like, you wouldn't be opposed to an RFC for getting it into 7.0. Is that what I understood? If so, we'll have something in draft today. Thanks for the clarity! Anthony