Patrick ALLAERT wrote:
2012/11/28 Lester Caine<les...@lsces.co.uk>:
>There is no 'objection' to deprecating the extension, but adding
>E_DEPRECATED to the code is problematic since that should NOT be present in
>a PECL version of the code?
Sorry, but removing the E_DEPRECATED notice when moved to PECL is not
part of the proposed RFC and should certainly not happen.
If ext/mysql is deprecated, it can perfectly live in PECL while
remaining deprecated. There ARE (supported) replacements for ext/mysql
and even if someone really one to use it, it should still be
considered deprecated regardless of the repository holding the code.
>Adding it in one location and not the other does
>not make sense.
Absolutely! There is no reason to remove that kind of notice in the future.
Then perhaps a few more people will start complaining as well then. There is NO
reason to have deprecated messages on legacy packages in PECL no other older
packages have them? So why pick out this one?
This NOT the way to handle retiring well used legacy extensions and it just gets
in the way of using E_DEPRECATED when it IS needed! At the very minimum we
should be able to ignore warnings when they are well understood without having
to hide everything else as well :(
--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
