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