Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:106635 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 69940 invoked from network); 16 Aug 2019 18:39:30 -0000 Received: from unknown (HELO localhost.localdomain) (76.75.200.58) by pb1.pair.com with SMTP; 16 Aug 2019 18:39:30 -0000 To: internals@lists.php.net References: <6534c240-e721-d5c1-a98c-86dfb9189b00@gmx.de> Date: Fri, 16 Aug 2019 17:08:40 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <6534c240-e721-d5c1-a98c-86dfb9189b00@gmx.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Posted-By: 94.4.34.143 Subject: Re: [PHP-DEV] Vote: Straw poll for P++ feasibility From: markyr@gmail.com (Mark Randall) Message-ID: On 16/08/2019 11:18, Christoph M. Becker wrote: > It is not necessarily required to have an implementation for an RFC > available, see item (6) in . I have enormous respect for Derick, but I can't help but feel this "RFC" was bodged from the start. There's certainly a place for straw polls, the ability to receive quick feedback on opinions and sentiment can be a positive thing in a lot of circumstances. This however, seemed more like an invitation for internals developers to express that they wouldn't entertain spending any time on the proposal, in effect forcefully slamming the door shut on it before a proper discussion had been had. The end result did seem to be like watching Zeev be thrown to the lions in the colosseum. While entertaining for a short time, I believe it left something of a sour taste in the mouth, and it certainly did not present internals well to the outside world. The hasty edits to the Wiki then made it worse, and so on. I believe for anything remotely positive to come out of this whole affair, things need to quickly and visibly pivot to a meaningful discussion about the long term game plan for PHP, and build a consensus on things such as strict typing, overloading in the core functions, and perhaps most divisively, if "cleaning up the language" is in itself a viable justification for backwards compatibility breaks, and if so, what weight it should carry. Mark Randall