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 <divinit...@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 <pierr...@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 >> >
