On 21/11/12 16:08, Adam Harvey wrote:
On 21 November 2012 13:03, David Muir <davidkm...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
