# RFC: Add a deprecated modifier for functions - Thread: https://externals.io/message/64435 - Original archive: https://news-web.php.net/php.internals/64435 - Started by Yussuf Khalil on 2012-12-26T14:22:37+00:00 - Messages: 11 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #64435 — Yussuf Khalil — 2012-12-26T14:22:37+00:00 URL: https://externals.io/message/64435#64435 Hello, I have created an RFC about adding a deprecated modifier for functions in PHP, see https://wiki.php.net/rfc/deprecated-modifier. What are your thoughts on this? Thank you, Yussuf Khalil --- ## #64436 — Yahav Gindi Bar — 2012-12-26T14:28:48+00:00 URL: https://externals.io/message/64435#64436 · In reply to: #64435 > Hello, > > I have created an RFC about adding a deprecated modifier for functions in > PHP, see https://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 can be great. What do you think? --- ## #64437 — Yussuf Khalil — 2012-12-26T15:48:12+00:00 URL: https://externals.io/message/64435#64437 · In reply to: #64436 Hello, assuming that you are referring to the RFC about annotations (https://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 ) 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). > > > > […] > 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 can be great. > > What do you think? --- ## #64438 — Eugene L Kovalenja — 2012-12-26T21:04:35+00:00 URL: https://externals.io/message/64435#64438 · In reply to: #64435 Hello, Khalil Could you explain the pros of your proposal in comparison with the next one: Hello, > > I have created an RFC about adding a deprecated modifier for functions > in PHP, see https://wiki.php.net/rfc/deprecated-modifier. What are > your thoughts on this? > > Thank you, > Yussuf Khalil --- ## #64439 — johannes@schlueters.de — 2012-12-26T22:05:19+00:00 URL: https://externals.io/message/64435#64439 · In reply to: #64435 Yussuf Khalil wrote: >I have created an RFC about adding a deprecated modifier for functions >in PHP, see https://wiki.php.net/rfc/deprecated-modifier. What are your > >thoughts on this? I don't think we should add a new keyword for such a thing. Adding keywords breaks many things and causes trouble. johannes --- ## #64440 — Nikita Popov — 2012-12-26T22:08:17+00:00 URL: https://externals.io/message/64435#64440 · In reply to: #64438 On Wed, Dec 26, 2012 at 10:04 PM, Eugene L Kovalenja wrote: > Hello, Khalil > > Could you explain the pros of your proposal in comparison with the next > one: > > > 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 --- ## #64441 — Yahav Gindi Bar — 2012-12-26T22:12:02+00:00 URL: https://externals.io/message/64435#64441 · In reply to: #64437 > Hello, > > assuming that you are referring to the RFC about annotations ( > https://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 ) 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). > > > […] > > -- > > > > 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. --- ## #64442 — Yussuf Khalil — 2012-12-26T23:03:00+00:00 URL: https://externals.io/message/64435#64442 · In reply to: #64440 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 wrote: > > > […] > > 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 --- ## #64443 — Yussuf Khalil — 2012-12-26T23:04:46+00:00 URL: https://externals.io/message/64435#64443 · In reply to: #64439 Could you please explain why a simple keyword like T_DEPRECATED could break something? Yussuf Khalil > > > Yussuf Khalil wrote: > > […] > > I don't think we should add a new keyword for such a thing. Adding keywords breaks many things and causes trouble. > > johannes --- ## #64444 — Eugene L Kovalenja — 2012-12-26T23:16:08+00:00 URL: https://externals.io/message/64435#64444 · In reply to: #64442 Khalil, Short-form "deprecated" mark for internal php use - is not good practice, from my point of view (sorry if any :) ), but it is compensated by good documentation and measured pace of releases. For example, when one of PHP contributors mark the function as deprecated, it is the result will be something like that: PHP Deprecated: Function set_magic_quotes_runtime() is deprecated in ... When PHP Engineer is reading that, he goes to php.net/set_magic_quotes_runtime and anwers "Why? What should I use instead?". He got the answer! But, unfortunately, PHP language used in a lot of projects, where only one kind of documentation presents: it is the php codebase :) > 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 > > > […] --- ## #64445 — johannes@schlueters.de — 2012-12-26T23:42:51+00:00 URL: https://externals.io/message/64435#64445 · In reply to: #64443 Yussuf Khalil 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