Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124675
Precedence: bulk
MIME-Version: 1.0
References: <CANLbj-rn9kfQGzx=g0LP5AkRLeEWx3XDYNQ8FKf=uMDrRWLGAw@mail.gmail.com>
 <ba09ea49-ddb5-40b2-95d8-478528e85cae@gmx.de>
In-Reply-To: <ba09ea49-ddb5-40b2-95d8-478528e85cae@gmx.de>
Date: Mon, 29 Jul 2024 18:09:07 +0700
Message-ID: <CANLbj-pKS7Mgm6HiNmEoof02M6P4qpu4x8bkRG8MDQSrb2RkUQ@mail.gmail.com>
Subject: Re: [PHP-DEV] Deprecate ext/curl `CURLOPT_DNS_USE_GLOBAL_CACHE`?
To: "Christoph M. Becker" <cmbecker69@gmx.de>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
From: ayesh@php.watch (Ayesh Karunaratne)

> Actually deprecating the constant might require the RFC process, so
> maybe it's best to make it a no-op for now (and to deprecate for PHP
> 8.5/9.0 whatever is next).

You are right I also think making this no-op is the best way for now.

Notably, Symfony HttpClient uses the constant to **disable** this
feature. So if we were to deprecate the constant, it will cause
deprecation notices unnecessarily.

>
> But regardless of deprecation or no-op'ing, we should document the
> behavior, and tell users about alternatives to accomplish the same goal.

I will submit PRs to the php/doc-en about the outcome of this change.


Thank you for weighing in on this. There is PR 5094[^1] from you that
proposed to deprecate several `CURLE_` constants. If we were to no-op
this constant, I'd like to propose a deprecation RFC with all those
changes combined.

Thank you,
Ayesh.

[^1]: https://github.com/php/php-src/pull/5094