Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124695
Message-ID: <a5ef8ea5-7470-4172-af52-ca3bf4cc66be@gmx.de>
Date: Tue, 30 Jul 2024 23:43:25 +0200
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4
Content-Language: de-DE
To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>,
 "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>, internals@lists.php.net
References: <USzt7tZZlO1DmAbSTLhD-bqa23FqZn0zk2aah8Ndxgk9c7RY5PefQ8MjbYPUYAzr2_m4Cf-5AI4PuNBTS84rim_FNS6RaT-cWSv714HEvvU=@gpb.moe>
 <1a88918e-e808-d778-45e1-53797660e093@php.net>
 <CAPrKfG5Cw_nU7g7FR+t4C1-YZ8CDsDO_-sRs=yEsHO5kCTZL+A@mail.gmail.com>
 <95147d9d-d6e8-4396-bf0b-409c33679f90@bastelstu.be>
 <CAPrKfG4TijmZ_N9512_Fk9MBUNg=E6PjNTy-bCbV8CAj9_wX8A@mail.gmail.com>
 <CAPrKfG7Hi0SGbLA31V-9KjHM50QaX+Q=PptuO4+VMOrz7d9eBA@mail.gmail.com>
 <G9IiDe18a2ZhrXPA-zljNZsawKCZxlTn2ACfJpM32scdRkRflZ2rM6Ra8z88ZYDczomex4pffxZMpVhEjdB74YQXXNyqJkd7rQdDGA14HC0=@gpb.moe>
 <89096756-9f50-4b10-9630-d3b18e4b9c29@gmx.de>
 <d54b99fd-64ea-40f2-9fee-c904f1305893@app.fastmail.com>
 <3beb3488-94fc-484e-ac6c-ce7a7a0facd2@app.fastmail.com>
 <921dcf17-280b-4005-b31f-5811dbe5ce62@gmx.de>
 <7f787046-17e8-4272-bd00-074fc21b9808@bastelstu.be>
In-Reply-To: <7f787046-17e8-4272-bd00-074fc21b9808@bastelstu.be>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
UI-OutboundReport: notjunk:1;M01:P0:i53Th5Mwm6c=;4UqRbbdW9s94SVDvvsTD5hTx4ZG
 ZjhsFgshH6gwNUWjMrRJ7b0JqT7gua+/7VibTOVyE8wwAH1QYYBR+7NNMjBt8SXS4zfXdnqGJ
 VbcRCxi9ugV3BYMg3q6oZRYCB7+AsGM3Fmn0cfYL6E0b/YDQSd4jMAl/sn3A1UDeNPqBkv3PK
 lHnr5Hz4bmOLsop3IbuW8MaefjTnteBWHX/qqw3bzNv2ZeGrXevpXySqLcjnl5N192k+KsVIQ
 HTVSmLITIHns0A8+Hf6px+nbTcEjUTE/UJZWWaxw169TBiLvJ+sNIp8cuETP5Mqzob0vDiGEv
 22kyqaiZEJ7cgmEUNOic4WGdENat4nal3kZaEduJxHaSU7sl7wkNpISbSnqrtqFoE2oUOxqCR
 IAvzY/s81cFsluGJA+FFOBpqNKaHSuLFfVbahROzd67/HnE3/9II7oBZLEJJqiupLKNsM4FPG
 AMM9cnqs6l6YK/h6rxlEzleLN/cWwi1+sQVXW5dw42bFZ/jra4gQPQXpPtDBJtqtDjxii+G1P
 ETqnIhguB5ZcJ9xiMdDOvz/Ufke3rz2CrqeuNm3mmWa/Z/OR+4WjN5jdm1hx04wo0spSvTpkF
 zeqH62piTgEdIriSjguLKRWlRGF0C3buq+wyf4r9hM/6wue6Q5b6SQaUdopedwTASulGzmV5b
 tOdB+1922E2WjVZzANVoPzfAtWNzPJ7GqJOzX9imQyA3yk9FWQ2ZPAQo/0L1WkaFKHXtyv6JG
 njUkn2vlpXcQeyFl3sqrvYlw/fgLtEID8tXibBIZdO/tG/jeZ/MmsrHrJclDEFh8237ZdmqBl
 //fybDQ489c66axVl3bxF9JQ==
From: cmbecker69@gmx.de ("Christoph M. Becker")

On 30.07.2024 at 21:20, Tim D=C3=BCsterhus 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