Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:98657 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 1128 invoked from network); 28 Mar 2017 16:35:33 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 28 Mar 2017 16:35:33 -0000 Authentication-Results: pb1.pair.com header.from=php@fleshgrinder.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=php@fleshgrinder.com; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain fleshgrinder.com from 77.244.243.89 cause and error) X-PHP-List-Original-Sender: php@fleshgrinder.com X-Host-Fingerprint: 77.244.243.89 mx108.easyname.com Received: from [77.244.243.89] ([77.244.243.89:46208] helo=mx108.easyname.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 76/C4-61593-4D09AD85 for ; Tue, 28 Mar 2017 11:35:32 -0500 Received: from cable-81-173-135-61.netcologne.de ([81.173.135.61] helo=[192.168.178.20]) by mx.easyname.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1csu2H-00004r-4y; Tue, 28 Mar 2017 16:31:57 +0000 Reply-To: internals@lists.php.net References: To: Wes , PHP Internals Message-ID: <59a94e8d-5a2e-bcee-4918-362b1d6bebf8@fleshgrinder.com> Date: Tue, 28 Mar 2017 18:31:45 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-DNSBL-PBLSPAMHAUS: YES Subject: Re: [PHP-DEV][RFC][VOTE] Allow abstract function override From: php@fleshgrinder.com (Fleshgrinder) On 3/28/2017 6:50 AM, Wes wrote: > Hello PHPeeps, > > There hasn't been much discussion around the proposed feature, and I've > interpreted it as a good sign :P It is not a super important change but it > has some advantages, it's consistent with the recent improvements to type > variance and also with future ones. Also, it's hopefully not too hard to > implement. > > https://wiki.php.net/rfc/allow-abstract-function-override > > I've decided to start the vote. It will end two weeks from this message, on > 10th April 2017. > > Thanks in advance for participating. > > Wes > There is absolutely no BC break at all in this RFC. The current status of things makes no sense because it is inconsistent. Heck, even the fact that it is inconsistent shows that there are different rules for the same things. Semantically there is no difference between a class, an abstract class, or an interface. They are all classes, some simply omit implementation details and leave it to their subclasses. I hope this gets a yes, regardless of possible use cases, this is simply applying proper variant rules everywhere. -- Richard "Fleshgrinder" Fussenegger