Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:65312 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 30152 invoked from network); 29 Jan 2013 03:56:53 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 29 Jan 2013 03:56:53 -0000 Authentication-Results: pb1.pair.com smtp.mail=alan@roojs.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=alan@roojs.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain roojs.com designates 202.81.246.113 as permitted sender) X-PHP-List-Original-Sender: alan@roojs.com X-Host-Fingerprint: 202.81.246.113 akbkhome.com Received: from [202.81.246.113] ([202.81.246.113:40131] helo=akbkhome.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 52/12-28517-28847015 for ; Mon, 28 Jan 2013 22:56:52 -0500 Received: from 255-001.netfront.net ([202.81.255.1] helo=[192.168.18.59]) by akbkhome.com with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Mailfort v1.2) (envelope-from ) id 1U02JN-0004HD-ET; Tue, 29 Jan 2013 11:56:41 +0800 Message-ID: <51074873.5090600@roojs.com> Date: Tue, 29 Jan 2013 11:56:35 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.4) Gecko/20120510 Icedove/10.0.4 MIME-Version: 1.0 To: Zeev Suraski CC: Gustavo Lopes , PHP Internals References: <1460659e-237d-4c7c-8cfa-523ec857d646@email.android.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-mailfort-sig: 0b3c2af616ed081781e2ee43aecfd204 Subject: Re: [PHP-DEV] [VOTE] Deprecate and remove calls from incompatible context (example of real usage that will break) From: alan@roojs.com (Alan Knowles) On Monday, January 28, 2013 11:30 PM, Zeev Suraski wrote: > Alan, > > Can you explain why you think it's a major BC break? The RFC suggested that > the BC break would be minimal and that the likelihood a lot of people used > it is very low. If you think differently and share it it might put it in a > different light. > > Zeev This is an example of recently written code that from my understanding will now generate a E_DEPRECATED based on that RFC http://git.roojs.org/?p=pear;a=blob;f=Document/Word/Writer/Section/TextRun.php;hb=HEAD#l136 The concept there is Class ... Section Class ...Section_Footer extends ...Section Class ...Section_TextRun extends ..Section The method 'addPreserveText' is in Footer, however the method is needed in TextRun, so It's called statically (expecting $this to be similar, as the both extend the same base class). Yes, this could be fixed other ways (putting addPreserveText to 'Section') or a Trait, however the current method has a number of benefits a) the code is easy to follow - hence we can get anyone to understand it quickly. b) putting it in the parent class would expose it to the children (where it may not be valid) c) traits would add a little extra complexity, and make the code a little bit more difficult to follow. I've used this in other places, it's basically lightweight traits, and has always been perfectly valid code. There does not seem to be a clear justification for deprecating it other than, It's not the way 'some' people like code to work... Regards Alan