Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:64009
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.42 as permitted sender)
Message-ID: <50AC6D70.3080303@gmail.com>
Date: Wed, 21 Nov 2012 16:58:08 +1100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2
MIME-Version: 1.0
To: Adam Harvey <aharvey@php.net>
CC: Anthony Ferrara <ircmaxell@gmail.com>, 
 "internals@lists.php.net" <internals@lists.php.net>
References: <CADajX4CYZdNpgQv46m_6J7tQLBc=h6HxCn-bGpxr3Ou2VaqgBg@mail.gmail.com> <CACwt+JeLin8aLtmBedO+DnJ4cz0Ajb75depkd7v_QK1NORUPOg@mail.gmail.com> <CADajX4CmOEBy3aZOh+qpfmq=OTiLF6+EuOyiRWM2bx7JxZumrg@mail.gmail.com> <50A9F799.5080909@codeangel.org> <CADajX4CbLLagJnO+dkZsGXkaS8h7rabtmpOz6Gos0KqcHOpsMA@mail.gmail.com> <CAAyV7nF3VyvCa_YCYrtaajm8b8CpTCUq7M6=07hJ5eCGBaUZrA@mail.gmail.com> <CADajX4AxoK73x-CoJx71j6g3ndiMbF2LYhnLrs2p_CcOBxmgjQ@mail.gmail.com> <50AC60BC.1030207@gmail.com> <CADajX4AtDA6i1Xr0voT5gke+qtPaxu3Yh-6wGvuLQf-o8UBwKQ@mail.gmail.com>
In-Reply-To: <CADajX4AtDA6i1Xr0voT5gke+qtPaxu3Yh-6wGvuLQf-o8UBwKQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] RFC: ext/mysql deprecation
From: davidkmuir@gmail.com (David Muir)

On 21/11/12 16:08, Adam Harvey wrote:
> On 21 November 2012 13:03, David Muir <davidkmuir@gmail.com> wrote:
>> On 21/11/12 15:47, Adam Harvey wrote:
>>> 2. If we decide not to generate E_DEPRECATED notices in PHP 5.5, what
>>> should the next course of action be:
>>>     (a) Enhance the manual text to make the soft deprecation clearer,
>>> and generate E_DEPRECATED notices in PHP 5.6
>>>     (b) Enhance the manual text to make the soft deprecation clearer,
>>> but take no further action in terms of E_DEPRECATED for the forseeable
>>> future
>>>     (c) Remove the warnings from the manual and undeprecate ext/mysql
>>> entirely
>> Has 2(c) been even suggested?
> Not that I've seen, but having a "none of the above, I want none of
> this" option seems prudent.

Except it's "lets reverse the changes already made", not "none of the 
above".

>
>> I take at that 2(b) is for those advocating "Move to PECL with no
>> E_DEPRECATED notices being thrown"?
> Not really. We can't really unbundle and move to PECL without
> deprecating first anyway, IMO. It's basically the option for no real
> change but clarifying the manual wording, since nobody seems satisfied
> with it.

No other extension was deprecated before moving to PECL, so why the 
extra hurt for ext/mysql? As I've said before, it doesn't makes sense to 
have it throw notices while it's in core, then no longer throw notices 
once moved to PECL. If the plan is to drop it completely, and not move 
it to PECL, then deprecation notices do make sense as there's no other 
recourse once the extension is removed.

In that case we really should have 3 questions:

Should ext/mysql generate E_DEPRECATED notices in PHP 5.5? (yes/no)
Should ext/mysql be moved to PECL or dropped completely in the future 
(PECL/dropped)
Should the manual text be changed to make soft deprecation clearer? (yes/no)


>
> Or, to put it another way from where I sit: the "too hard, let's make
> a decision after stringing people along longer" option.
>
> Adam

Cheers,
David