On Thu, Jun 30, 2022 at 10:48 AM Pierrick Charron <pierr...@php.net> wrote: > > Hi all, > > > > - The new CurlUrl class should probably be immutable from the start. It > > was my biggest mistake not to do that with DateTime. > > > > > After thinking about it and some discussions, I followed Derick's > recommendation and therefore changed the RFC to make the CurlUrl class > immutable. All the setters were replaced by new `with*` methods. > For example setHost is now withHost and will return a new object with the > host modified. This will prevent confusing behavior where the CurlUrl > object would be unintentionally modified after being attached to a > CurlHandle. > > Pierrick
It's clear people do not agree on how we should be designing the APIs for 3rd party extensions. However, let me redraw attention to the introduction of the RFC: > One of the goal of this API is to tighten a problematic vulnerable area > for applications where the URL parser library would believe one thing > and libcurl another. This could and has sometimes led to security > problems. Designing another API on top of what libcurl provides _could make the problem worse_. I am fine with these kinds of adjustments: 1. Using exceptions instead of return codes. 2. Using enums instead of constants if it makes sense (it may not if they are bitwise-or'd together, which is pretty common for C libs). 3. Renaming things that have keyword or reserved word conflicts. I am not fine with designing an immutable, with* style API that doesn't mirror the underlying library at all. At least, not by itself; I'd be okay with having both, where the nicer API is built on top of the lower level, but what is nicer is subjective. As this thread shows, designing a nicer API will have quite a bit more discussion and disagreement than "exposing" or "porting" libcurl's API. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
