That's OK with me.( putting it on-list, heh )
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;
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'.
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
