RFC: Add a deprecated modifier for functions

Hello,

assuming that you are referring to the RFC about annotations (
https://wiki.php.net/rfc/**annotationshttps://wiki.php.net/rfc/annotations)
I don't think that annotations are needed in PHP. Declarations that
actually have an impact on the language itself (like deprecated) should
rather be implemented as function modifiers while annotations with simple
information (like <Author("Mr. X")>) can also be stored in the doc comment
(as @author Mr. X). However, I see that Reflection methods like
getAnnotation() and hasAnnotation() can be useful sometimes. We could
implement methods that fetch information from the doc comment for these
cases, for example getDocTag($name) and hasDocTag($name).

Hello,

I have created an RFC about adding a deprecated modifier for functions in
PHP, see https://wiki.php.net/rfc/****deprecated-modifierhttps://wiki.php.net/rfc/**deprecated-modifier
<https://**wiki.php.net/rfc/deprecated-**modifierhttps://wiki.php.net/rfc/deprecated-modifier

.

What are your thoughts on this?

Thank you,
Yussuf Khalil

--

Hi!
I think the idea of marking functions as deprecated is great and the
current way of throwing E_DEPRECATED error by trigger_error can be
improved. In the current state.

That's being said, I don't think that adding a deprecated keyword is the
solution, since now we can write documentation and set a "@deprecated"
mark.
I think, that the best solution is the attributes concept that was
rejected
before and should be re-considered after the last releases changes and
language improvements.
A few built in attributes, such as <Deprecated> can be great.

What do you think?

--

The point of adding a methods to get annotations from the docblock is good
for itself and I think that we should create RFC about it.
However, I do think that because annotations gives you to execute custom
code it has pros that the deprecated keyword or any other keyword can't
gives you.

Because it's not a discussion about annotation and I've suggested it as an
alternative I'll back to the topic.

I have to agree with Eugene and Nikita since as I see it, the current
implementation has limitation that trigger_error solve. In addition, even
now when using modern IDE and setting @deprecated annotation in the
docblock you can see a warning when calling this method, so I don't see
much reason to add a keyword just for that.

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 iam@purple.org.uawrote:

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

Yussuf Khalil dev@pp3345.de wrote:

Could you please explain why a simple keyword like T_DEPRECATED could
break something?

It breaks everything using "deprecated" as function name, constant, property name, class name, method name, ... as the parser doesn't know much about the meaning and context.

johannes