Throwing an E_USER_DEPRECATED error sure is an alternative. However, I
think that using a deprecated keyword instead is cleaner and faster. A
native function (set_magic_quotes_runtime() for example) just needs the
ZEND_ACC_DEPRECATED flag which can be added using a simple macro while a
userspace developer has to throw an error by himself. It seems a bit odd
that emitting a deprecated error in a PHP userspace function is more
difficult than it is for a PHP extension or core developer. Why do we
have the ZEND_ACC_DEPRECATED flag if we don't allow the user to actually
use it?
I agree that there are some cases where throwing a customized
E_USER_DEPRECATED error can be useful, but most users will be happy with
the normal E_DEPRECATED error thrown automatically when a function is
given the ZEND_ACC_DEPRECATED flag.
Yussuf Khalil
On Wed, Dec 26, 2012 at 10:04 PM, Eugene L Kovalenja <i...@purple.org.ua>wrote:
Hello, Khalil
Could you explain the pros of your proposal in comparison with the next
one:
<?php
function somethingWillBeRemovedInNextVe**rsion() {
trigger_error('This function is deprecated. '
. 'Please use "newFunction" instead. ',
E_USER_DEPRECATED);
// functionality below
return 'something';
}
function newFunction() {
// ...
}
somethingWillBeRemovedInNextVe**rsion();
From my point of view, the modifier for this kind of things is the
restriction for developers, who want to inform user about details like "why
we are going to remove this functionality".
I agree with Eugene. It's much better to throw a E_USER_DEPRECATED error
with a meaningful custom error message. So -1 on this.
Nikita
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
