Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:118145 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 25537 invoked from network); 30 Jun 2022 20:30:18 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 30 Jun 2022 20:30:18 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 9DCE7180545 for ; Thu, 30 Jun 2022 15:21:54 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-yw1-f174.google.com (mail-yw1-f174.google.com [209.85.128.174]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 30 Jun 2022 15:21:54 -0700 (PDT) Received: by mail-yw1-f174.google.com with SMTP id 00721157ae682-3177f4ce3e2so7174957b3.5 for ; Thu, 30 Jun 2022 15:21:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=datadoghq.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GrE5lGB80IWPxnMtPDAjbFjBwwdFXLOkkJk157Qtf2M=; b=aCcJjce5kohWL3LmMCeP4sjMsKGGWMqLG+ClWPw21eVOgB68lk9KBXIc2Rev8KpW7n zB3i62Rtsh+/O+Z8EM4rcQEgY77Ok9YMUDSvXIHmUJuKFCoJk1NXAmM0/4oPrQBB+cuJ xgjkf+YxGbu/Gv0DewFB7R85INgpPFiSEXqLM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GrE5lGB80IWPxnMtPDAjbFjBwwdFXLOkkJk157Qtf2M=; b=RuGnm7srduISWJZOV+oUM2RZyRl/Af/TY85Yh6EHf1ZY6l9pfDp/2NwFoQC67m2hm5 URrX4bxuJjCYYKJkKY7aU9stMyPreK4fofq3PKJdGnfHum89DElp/mV52GayjCC+2WHt wK8XVfDcvWwg+axEONGWS8SaIL4cSuqvjvhIIIaq9vkMJlO7F8RUSDpf6kaLPQ5X3Ncs y0/zse9UfegoMneVXfcn6586Yes8WKK9Phmv4f9XAbzNeL6S0xWk/A1rA0iTWzB2EIGR xR9tRCiwQCTsAhF4y8pcGa4LgODeSli3FJhyiHnIYutEUhiAFnZYnWCjZ2OMl3bAzvsi zSqA== X-Gm-Message-State: AJIora+LkJg0Fp/mXUGHu4P8SY4HVhv/wp2vKNQt7SzqbW1uz7aUEfDT W8W+FDeWFf3AGfgkcx91sYdKyK2fO01tl9dig7znsAY7YoAm+g== X-Google-Smtp-Source: AGRyM1vcV/YG+Fo29NnVyg2hQ/xKQqc9Qn7E1NQf24hbVq6HXfCnbO/vXisbL7FNFPvoqJ6aAsXb3xguE7GVJgHbM6A= X-Received: by 2002:a81:468b:0:b0:318:4cac:6576 with SMTP id t133-20020a81468b000000b003184cac6576mr12779892ywa.277.1656627713209; Thu, 30 Jun 2022 15:21:53 -0700 (PDT) MIME-Version: 1.0 References: <7CB0EB0B-700D-49F6-8223-00A9B16F463B@php.net> In-Reply-To: Reply-To: Levi Morrison Date: Thu, 30 Jun 2022 16:21:42 -0600 Message-ID: To: Pierrick Charron Cc: Derick Rethans , PHP internals Content-Type: text/plain; charset="UTF-8" Subject: Re: [PHP-DEV] [RFC] [Under Discussion] New Curl URL API From: internals@lists.php.net ("Levi Morrison via internals") On Thu, Jun 30, 2022 at 10:48 AM Pierrick Charron 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.