Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:64442 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 64083 invoked from network); 26 Dec 2012 23:03:39 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 26 Dec 2012 23:03:39 -0000 X-Host-Fingerprint: 84.177.155.112 p54B19B70.dip.t-dialin.net Received: from [84.177.155.112] ([84.177.155.112:3311] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id A4/02-43002-A428BD05 for ; Wed, 26 Dec 2012 18:03:38 -0500 Message-ID: To: internals@lists.php.net Date: Thu, 27 Dec 2012 00:03:00 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 References: <8D.41.07178.7380BD05@pb1.pair.com> <50DB6663.7010000@purple.org.ua> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 84.177.155.112 Subject: Re: [PHP-DEV] RFC: Add a deprecated modifier for functions From: dev@pp3345.de (Yussuf Khalil) Throwing an E_USER_DEPRECATED error sure is an alternative. However, I think that using a deprecated keyword instead is cleaner and faster. A native function (set_magic_quotes_runtime() for example) just needs the ZEND_ACC_DEPRECATED flag which can be added using a simple macro while a userspace developer has to throw an error by himself. It seems a bit odd that emitting a deprecated error in a PHP userspace function is more difficult than it is for a PHP extension or core developer. Why do we have the ZEND_ACC_DEPRECATED flag if we don't allow the user to actually use it? I agree that there are some cases where throwing a customized E_USER_DEPRECATED error can be useful, but most users will be happy with the normal E_DEPRECATED error thrown automatically when a function is given the ZEND_ACC_DEPRECATED flag. Yussuf Khalil > On Wed, Dec 26, 2012 at 10:04 PM, Eugene L Kovalenja wrote: > >> Hello, Khalil >> >> Could you explain the pros of your proposal in comparison with the next >> one: >> >> > >> function somethingWillBeRemovedInNextVe**rsion() { >> trigger_error('This function is deprecated. ' >> . 'Please use "newFunction" instead. ', >> E_USER_DEPRECATED); >> >> >> // functionality below >> >> return 'something'; >> } >> >> function newFunction() { >> // ... >> } >> >> somethingWillBeRemovedInNextVe**rsion(); >> >> >> From my point of view, the modifier for this kind of things is the >> restriction for developers, who want to inform user about details like "why >> we are going to remove this functionality". >> > > I agree with Eugene. It's much better to throw a E_USER_DEPRECATED error > with a meaningful custom error message. So -1 on this. > > Nikita >