Derek Ford wrote:
Andi Gutmans wrote:
That's OK with me.
At 04:42 PM 11/19/2003 -0600, Derek Ford wrote:
Derek Ford wrote:
Andi Gutmans wrote:
At 11:53 AM 11/19/2003 -0500, George Schlossnagle wrote:
I agree with --disable-deprecated, it seems to be the best
option. Do you think it would be relevant to have a php.ini
option for this?
What's the point of deprecating things if you never remove them?
Seems like an empty threat. And --disable-deprecated seems like
a horrible idea to me - it greatly reduces the portability of
scripts and increases the wtf factor by having them runable in
some places and not runnable in others.
I guess we should stick to only E_STRICT then, and find a nice
general way of making deprecated function calls warn people.
I don't think we should nuke such functions because it would break
all scripts and we should give people a chance to use E_STRICT to
track all of this stuff. Maybe we can nuke the stuff for PHP 5.5
but it's not that critical. By nuking the functionality we will
hurt more users than we will help users.
Andi
I was just told of an old list discussion over E_DEPRECATED. Why
not drag that idea back in? I missed it, so I don't know the milk
and cookies, but it seems to me to be a good idea.
erm, advancing on the idea;
(posting this off-list so I don't look like a fool if this is overly
idiotic :)
case E_USER_NOTICE:
error_type_str = "Notice";
break;
+ case E_DEPRECATED:
+ error_type_str = "Deprecated
Functionality";
+ break;
+ case E_STRICT:
+ error_type_str = "Strict Standards";
+ break;
default:
error_type_str = "Unknown error";
break;
( putting it on-list, heh )
This would allow us to keep E_STRICT after we remove the deprecated
functions altogether, and cast E_DEPRECATED aside. E_STRICT could
still be used as you (andi) planned, with 'advisory stuff'.
I don't like branching the subject out too much, but I figure this is
relevant enough; why don't we add register_globals to the E_DEPRECATED
functionality? It would give fair final warning, and we could finally
get rid of the functionality completely at a relevant time.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
