On 30.07.2024 at 21:20, Tim Düsterhus wrote: > What prevented me personally from adding a "soft deprecation" to the > documentation is, that the function is not actually deprecated and not > slated for deprecation. It is not up to me to decide to soft deprecate > something.
Well, yeah, that needs some discussion at least. > And regarding your remark of not reaching folks, I agree. uniqid()'s > documentation is already full of warnings, but folks still reach for it. "I haven't looked at the documentation, because I know what uniqid() does: it gives me a unique ID. I've read that 20 years ago in a great tutorial." ;) > I've proposed a deprecation instead of any other error level, because it > is the least severe error level we have available: Libraries and > Frameworks nowadays generally understand that deprecations are not hard > errors and thus do not convert these to exceptions, but instead just > direct them to a different log file / show them in the framework's > debugging toolkit. Thinking about it, deprecations are not really a problem, so no need for E_STRICT, that would unlikely help. The actual problem is that some projects try to be strict about deprecations (and would likely be about E_STRICT either), and others wait until the functionality is no longer availabe, anyway. There is probably no way to offer users a smoother upgrade path. Cheers, Christoph
