Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:64444
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain purple.org.ua designates 81.17.140.213 as permitted sender)
Message-ID: <50DB8538.40107@purple.org.ua>
Date: Thu, 27 Dec 2012 01:16:08 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <8D.41.07178.7380BD05@pb1.pair.com> <50DB6663.7010000@purple.org.ua> <CAF+90c-D3m3kWfJCbowyEQJd4x66GuPMU3L1m8G1ikkfrhnpAQ@mail.gmail.com> <A4.02.43002.A428BD05@pb1.pair.com>
In-Reply-To: <A4.02.43002.A428BD05@pb1.pair.com>
Content-Type: multipart/alternative;
 boundary="------------070806020302030205090708"
Subject: Re: [PHP-DEV] RFC: Add a deprecated modifier for functions
From: iam@purple.org.ua (Eugene L Kovalenja)

--------------070806020302030205090708
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Khalil,

Short-form "deprecated" mark for internal php use - is not good 
practice, from my point of view (sorry if any :) ), but it is 
compensated by good documentation and measured pace of releases.

For example, when one of PHP contributors mark the function as 
deprecated, it is the result will be something like that:

    PHP Deprecated:  Function set_magic_quotes_runtime() is deprecated
    in ...


When PHP Engineer is reading that, he goes to 
php.net/set_magic_quotes_runtime and anwers "Why? What should I use 
instead?". He got the answer!
But, unfortunately, PHP language used in a lot of projects, where only 
one kind of documentation presents: it is the php codebase :)



On 12/27/2012 01:03 AM, Yussuf Khalil wrote:
> 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 
>> <iam@purple.org.ua>wrote:
>>
>>> Hello, Khalil
>>>
>>> Could you explain the pros of your proposal in comparison with the next
>>> one:
>>>
>>>     <?php
>>>
>>>     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
>>
>
>


--------------070806020302030205090708--