On Wed, 22 May 2024 at 11:01, Pierre <pierre-...@processus.org> wrote:
> Le 22/05/2024 à 09:33, Nicolas Grekas a écrit : > > Hi Benjamin, > > The vote for the RFC #[\Deprecated] attribute is now open: >> >> https://wiki.php.net/rfc/deprecated_attribute >> >> Voting will close on Wednesday 5th June, 08:00 GMT. >> > > I voted "no" because I think this is better addressed in userland, as this > gives more flexibility. > I would better have an attribute that is made only for static analysis > with no runtime side effects at all. > Being forced to make the attribute final because the implementation in the > engine requires is an example of why the engine is not the correct place to > send this notice. Another example is not being able to add the attribute on > classes because [engine reasons]. > > trigger_error() is better fitted for the runtime side-effect when it's > desired. > In my opinion, #[Deprecated] should be only for static analysers / > reflection (although this would need another discussion - I'm not sure this > would benefit being in the engine vs in a userland package. > > Thanks for the RFC anyway. > > Nicolas > > I'm always dubious when I read the "this can be addressed or better > addressed in userland": as soon as you need something as little as the > Deprecated attribute, if it's not in core but in userland, you encounter > two very serious issues: first one, fragmentation, every framework, > organisation, or static analysis tool will have its own variant, second one > if the community converges toward a single one, you then will be dependent > on a certain framework or huge tooling. > > I can see many benefits in having this in core, one being that every > static analyzer will implement it using the core attribute, so any project > and developer using it can choose any static analysis tooling without > having to change or adapt its code everywhere, or learning a different > convention in order to use different tools. > > That's my 2 cents, but the "better in userland" argument seems to me > almost always biased or wrong. Especially for this Deprecated argument, > this a very common need, and each project Doctrine, Symfony, any tool > implement it in a different manner. I don't want to be rude, but as a > developer using all of those, it's very annoying having to learn different > ways of doing something as simple and naive that saying that a function is > deprecated. One manner is sufficient, even if not perfect. > > -- > > Pierre > Hello everyone. I have to agree with Pierre on this one as a userland developer. To give a good illustration: Guzzle. I'm trying to get rid of it in my code base and use SF HttpClient (mostly for the sole reason that guzzle truncates replies in their exceptions without any ability to configure that and cutting off all actually useful information about why request failed) and... I can't... Because some other package is hardwired to Guzzle and refuses any attempts to inject a different HttpClient. Which forces me to roll my own implementations, thankfully making API clients is fairly simple. A Deprecated attribute belongs in the core. -- Arvīds Godjuks +371 26 851 664 arvids.godj...@gmail.com Telegram: @psihius https://t.me/psihius
