Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118051
MIME-Version: 1.0
References: <CAOfKkdTjPiZHnSHuag_+fmFK-1Advh2-vfDgbJBXEmK=72NB0g@mail.gmail.com>
 <7CB0EB0B-700D-49F6-8223-00A9B16F463B@php.net> <CAOfKkdTKuj3nbi7ORMzpYDE2Yn5aKX-E64JdH2PR4qDXqfPiAg@mail.gmail.com>
 <CAJmy8YGCOLaZSt5s=RQVD+uKDbVrwYBYZjQS4gLRLkkVjZ0nqw@mail.gmail.com> <CAJmy8YGdjb1twukj7R7dj0HvKBjq5wxE3TutSRLk4feDSqSPSA@mail.gmail.com>
In-Reply-To: <CAJmy8YGdjb1twukj7R7dj0HvKBjq5wxE3TutSRLk4feDSqSPSA@mail.gmail.com>
Date: Wed, 22 Jun 2022 16:56:57 +0200
Message-ID: <CAJmy8YF2Tzh7hF6r6JRx+ribS3pfxX_M2F0WsU8pDxD0tA0qKA@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000990e2805e20a8e78"
Subject: Re: [PHP-DEV] [RFC] [Under Discussion] New Curl URL API
From: divinity76@gmail.com (Hans Henrik Bergan)

--000000000000990e2805e20a8e78
Content-Type: text/plain; charset="UTF-8"

(dammit, mixed sftp:// with ftps:// there, ignore that, i meant sftp:// )

On Wed, 22 Jun 2022 at 16:53, Hans Henrik Bergan <divinity76@gmail.com>
wrote:

> nitpicking but I kind-of doubt the description
> for CurlUrl::NO_DEFAULT_PORT is correct, quote:
> > Instructs the method to return null if the port matches the default port
> for the scheme.
>
> makes it sound like these would return null: http://localhost:80/
> https://localhost:443/ ftps://localhost:22/
>
> Is that correct? I would imagine it returns null if the port isn't
> specified, rather than null if the port when specified matches the default
> port?
>
> On Wed, 22 Jun 2022 at 16:46, Hans Henrik Bergan <divinity76@gmail.com>
> wrote:
>
>> any particular reason CurlUrl::getPort() defaults to 0 rather than one of
>> the valid options? (that being CurlUrl::DEFAULT_PORT
>> and CurlUrl::NO_DEFAULT_PORT )
>>
>> On Wed, 22 Jun 2022 at 16:23, Pierrick Charron <pierrick@php.net> wrote:
>>
>>> Hi Derick,
>>>
>>>
>>> >
>>> > - The new CurlUrl class should probably be immutable from the start. It
>>> > was my biggest mistake not to do that with DateTime.
>>> >
>>> >
>>> Thanks for sharing your lessons learned. But I still see some use cases
>>> where mutable objects are easier to use. From the experience you had with
>>> DateTime, do you think that having `CurlUrl` being immutable and
>>> providing
>>> a `MutableCurlUrl` would make sense ? I see some cases where you
>>> "navigate"
>>> on a website using the same CurlHandle and just want to manipulate the
>>> MutableCurlUrl handle to change urls.
>>>
>>>
>>> > - What happens if the curl library available on the system does not
>>> have
>>> > the features and functions that this new class relies on? I would
>>> expect
>>> > the class to not be available either, but the RFC does not mention
>>> that.
>>> >
>>>
>>> Good point. As you expected, if the functions are not available in
>>> libcurl,
>>> the class will not be available. Same thing for each constant/feature.
>>> The
>>> extension will "adapt" to the curl version. I will add this to the RFC.
>>>
>>> Pierrick
>>>
>>

--000000000000990e2805e20a8e78--