On 11/15/2012 11:27 PM, Pierre Joye wrote: > hi Anthony, > > On Thu, Nov 15, 2012 at 9:11 PM, Anthony Ferrara <ircmax...@gmail.com> wrote: > >>> Actually, no it wouldn't. You still get the overhead of the error, plus >>>> any custom error handlers will be triggered regardless of the >>>> error_reporting setting which depending on the implementation of the >>>> error handler can be quite costly performance-wise. >>>> >>> >>> So what solution is there to this? Should it not be deprecated? This same >>> issue (is still happening) with register_globals for us, but it's >>> acceptable as it has been phased out. Should there be no deprecation >>> warning now and wait for a future release? >>> >> >> That's my suggestion. Officially deprecate it, but don't add E_DEPRECATED >> to it in 5.5. Update the documentation, and start a PR campaign to get off >> it. Then in NEXT add E_DEPRECATED and in NEXT+1 remove it. > > This does not make sense, at all. > > We introduce this flag and used it already a lot in many parts of PHP > (engine included) for this exact purpose. Most major apps have mysqli > support or provide working solutions to support mysqli, incl. for > plugins (like wordpress, which is likely to support mysqli in Q2 > 2013). > > Not adding the E_DEPRECATED flag would be a mistake and will only add > more confusions by the time we will move it out.
Actually we have never used E_DEPRECATED to deprecate an entire extension. We have deprecated specific functions and engine features, but for entire extensions we have provided alternatives and/or waited for them to become inconsequential and then moved them to pecl. But we certainly never littered the extension with warnings before moving it out. How do you see adding E_DEPRECATED working here? Do we add it to every function in the extension? Just to some? And then when we move the extension to pecl do we pull the warnings back out? Surely it makes no sense to move an extension out of core to pecl and spew E_DEPRECATED warnings to people who explicitly choose to install it. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
