Hi Anthony, > -----Original Message----- > From: Anthony Ferrara [mailto:ircmax...@gmail.com] > Sent: Saturday, August 22, 2015 4:44 AM > To: Pierre Joye <pierre....@gmail.com> > Cc: Anatol Belski <anatol....@belski.net>; Scott Arciszewski > <sc...@paragonie.com>; Niklas Keller <m...@kelunik.com>; Trevor Suarez > <ric...@gmail.com>; PHP internals <internals@lists.php.net> > Subject: Re: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7 > > Pierre > > On Aug 21, 2015 22:33, "Pierre Joye" <pierre....@gmail.com> wrote: > > > > On Sat, Aug 22, 2015 at 9:16 AM, Anthony Ferrara <ircmax...@gmail.com> > wrote: > > > > > If that's what it will take I will happily draft one tomorrow morning. > 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 specific > release. > I would like to respect that. If they say no, I won't waste time and energy > 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 another > 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 is that quite a new stuff in Throwable was taken already after release circle start and the point of no accept for the new RFCs. In any case, by the times 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 matter 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 already at that time was to bring all the bike shedding onto a productive path and to avoid a situation like it is now. Actually this argument is nothing 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 main >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 all >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 and >possible inconsistency consequences, or CSPRNG functionality can be deferred >until a complete solution, or CSPRNG can be reimplemented as class where >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 release >slots until final yet. Were it an RFC which is accepted, the change would 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 affects long >term features and language paradigm, which is the matter of the community >competence. There's the 7.0 timeline which is a voted thing, there is a >release process document which defines that the votes take place on RFCs >directly and not on the mailing lists. The RMs belief is that the suggested >change is the exact kind of needing a collective decision. Due to the concerns >explained earlier, the timeline RFC and other items seem to be in clash with >the change how it is proposed ATM. To undo/change any of those items to pass >the suggested change in, another RFC seems to be inevitable. With the hope >that the cautions expressed were taken into account it's up to everyone to >take actions and make a choice they hold for right. Anthony, sincere thanks for your activity and open minded handling in this affair. Best regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
