hi Rasmus,
On Fri, Nov 16, 2012 at 9:36 AM, Rasmus Lerdorf <ras...@lerdorf.com> wrote:
> 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.
I see a couple of options:
1. On extension load
Useful for ISPs so they will see it by updating PHP
2. On extension load and on connect
Useful for users and ISPs
3. All functions
Performance impact, but I do not have a problem with that. If
someone worries about performance, he should have moved to mysqli
already since long.
About the (later) move to PECL, the installer shows superseded
warnings. Sadly it is not shown by distros tools but we can't cover
all cases anyway. If we go with option 1 or 2, I would keep the
warning in place as well.
Cheers,
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
