Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:126523 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id 1568D1A00BC for ; Fri, 28 Feb 2025 08:38:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1740731763; bh=/kvaXrdlS/N5Yy6ycx2ItjzdVI5KWqNWaBsBiCQkiwA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=R/txDLSLgyBrQMdF020mS3qZ/dtpHcUOoyd/f+2ujy3ehnGk/cBmAWcGSq7jxvp0G KtBO2F6rwju1e6JDsIilalgYY81sUVWS3c5tHr7IaIn/AxpJ9DOp7HC/vyEE1ulLLN JiZQAoATBCqRqhWIaqPNEt10OSqeLIft3h0/4OAwnCwjg+sMyFYgijkZQrQ7oRz9Ry DMHhzl6JRqpewiaPHKIwRIX1+lPgsgGAP1fqGObxMhUkmSCFGnRkRCAvdh7UNg510E mQMUTfGzL5CnOUoF3kJdb3ulcBP0x6pLU50V+KN2WH/pwn4uu+9289X2rSpz0tjtRX PiLFDERS6qD0A== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 67C5F180061 for ; Fri, 28 Feb 2025 08:36:02 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-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,DMARC_PASS,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from mail-ej1-f41.google.com (mail-ej1-f41.google.com [209.85.218.41]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Fri, 28 Feb 2025 08:36:01 +0000 (UTC) Received: by mail-ej1-f41.google.com with SMTP id a640c23a62f3a-abb7f539c35so342832066b.1 for ; Fri, 28 Feb 2025 00:38:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740731918; x=1741336718; darn=lists.php.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=/kvaXrdlS/N5Yy6ycx2ItjzdVI5KWqNWaBsBiCQkiwA=; b=c5DEtnx1tLGI1eQhamz1oodpLREWir+eZe+t9RT5ESUDwI7uiJsPDDR4M/ItmzGO5C z4OYlWhkFVRMI2mgZEcJHSDSbgOtxA39sQu5c3Hicce2/IZ3Xfpi49OU8z52S6UEl7QN bTbkYBn064gJhU9wXsXxzZia0feDLU/VfXnM/iFUTXllcwUCQPHuiS/od/ay/E3z5C/x jG8wWvO8Y3wPkSIGoY6xjFsGxF3/GdGKgeEGoTR5O8ZjMK48t/hHrn96+85HK5ImyXis dhkIRG8wkRF54DVJPQ4nVoi3cy/MdGVtRgbYEz/av3ngkMoBRXR/Veg0JruDOnZvmpgw sSUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740731918; x=1741336718; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=/kvaXrdlS/N5Yy6ycx2ItjzdVI5KWqNWaBsBiCQkiwA=; b=HrNEToMv5k3JxkOx/fTTdGMpcd3Maq9zbOeHaLGm0u+G/J3GIcOsbEYbeKWafn/36k XEdXo3xoQQJG4tZBDsOOVQWUMqoPPe/8BeJgdy6w5ieHBdTHRD7OM+GAiFPIUQdVcaOG t4bzYMlcX72vfrOuvHfvro6fevNJ3nYz16Yw+0Vy3POpICiYUTh84us0UMV3GPpXt+A/ F6bbpfiV9nlWU1M2hW31XUlq73Vt69UNzAsv4uvXorfdiDLXpm0J2ggTNCWf4ddrP24E gvYxUQrbxIhF7d/F/QngpNFs33a1NRcFtXv7X7SbayF75s4OVAv8sYw39s8tntM3W9ng Farw== X-Forwarded-Encrypted: i=1; AJvYcCW+QaWBlMaNQxfbqMNOyxiysgiRWnbGAFZz6xWsoXW1JHOlfu6w0hK/P3GiaE85Qfc9/OevPjbGCq8=@lists.php.net X-Gm-Message-State: AOJu0YyV51E2wrRMcVTUUv+KH5mH6jc595F1WYKLUFr8r2VnJjXr1rY4 FYGROSuJ7y8wH0YGzdyNzA3c5jlk0PEudeIHz3MOlV3t54q9AhafSRa2p6qZWRVmBu6NTTfP8WH saAug7f8gdewd017cTmbB94Tglb8= X-Gm-Gg: ASbGncvr5SuCz97LxtV7WePXo4BYYYIAd2FMqY4u1xutYgLlt8RhieawPp4yT/vEQU8 XxyZMJPURBVSguXIpVi+PN2A4evrbDXOS3BcjnzU6k0lncUPRpNg/0oAlsJPTdhMI3ATOnm8KC7 tBY7uC0g== X-Google-Smtp-Source: AGHT+IFnhbeD4oRxBNWpqMbJgobFCsXbRgeDp3cSGdJJjgoYuOHlePhbHIBMfGiBLBVMnWHvYECA5KADpTIZsNGd1Rs= X-Received: by 2002:a17:907:6e8a:b0:ab6:c4e0:2d18 with SMTP id a640c23a62f3a-abf25fdbdbemr260042866b.16.1740731917980; Fri, 28 Feb 2025 00:38:37 -0800 (PST) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 References: <811B65CE-1DF0-4A47-937C-4FCB6E945B92@pmjones.io> <19377F60-FB7F-4E6E-A085-4DCB6CD92234@pmjones.io> <7B7987C6-37F3-432A-8BA2-9D93F428FAD5@pmjones.io> <93898e96-bbd6-4c2e-a1ad-35499bb2510d@app.fastmail.com> In-Reply-To: <93898e96-bbd6-4c2e-a1ad-35499bb2510d@app.fastmail.com> Date: Fri, 28 Feb 2025 09:38:11 +0100 X-Gm-Features: AQ5f1JqftiGMkn9tZFIxc2AoeqCZT9sqf8rOWC50QrY5h-zlDdsgTPlVX8vNvKE Message-ID: Subject: Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API To: Rob Landers Cc: Faizan Akram Dar , "Paul M. Jones" , ignace nyamagana butera , =?UTF-8?Q?Tim_D=C3=BCsterhus?= , "Gina P. Banyard" , PHP Internals List Content-Type: multipart/alternative; boundary="0000000000009ef019062f2fbbbd" From: kjarli@gmail.com (Lynn) --0000000000009ef019062f2fbbbd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Feb 28, 2025 at 12:05=E2=80=AFAM Rob Landers wr= ote: > > > On Thu, Feb 27, 2025, at 22:01, Faizan Akram Dar wrote: > > Hi, > > > On Thu, 27 Feb 2025, 20:55 Paul M. Jones, wrote: > > > > On Feb 25, 2025, at 09:55, ignace nyamagana butera > wrote: > > > > The problem with your suggestion is that the specification from WHATWG > and RFC3986/3987 are so different and that the function you are proposing > won't be able to cover the outcome correctly (ie give the developper all > the needed information). This is why, for instance, Mat=C3=A9 added the g= etRaw* > method alongside the normalized getter (method without the Raw prefix). > > The two functions need not return an identical array of components; e.g., > the 3986 parsing function might return an array much like parse_url() doe= s > now, and the WHATWG function might return a completely different array of > components (one that includes the normalized and/or raw components). > > All of this is to say that the parsing functionality does not have to be > in an object to be useful *both* to the internal API *and* to userland. > > > > > > It most definitely needs to be an object. Arrays are awful DX wise, there > is array shape which modern IDEs like phpstorm support and so does static > analysis but the overall experience remains subpar compared to classes (a= nd > objects). > > > I=E2=80=99m curious why you say this other than an opinion about develope= r > experience? Arrays are values, objects are not. A parsed uri seems more > like a value and less like an object. Just reading through the comments s= o > far, it appears that whatever is used will just be wrapped in library cod= e > regardless, for userland code, but the objective is to be useful for othe= r > extensions and core code. In that case, a hashmap is much easier to work > with than a class. > > Looking at the objectives of the RFC and the comments here, it almost > sounds like it is begging to be a simple array instead of an object. > > =E2=80=94 Rob > Depends on there being the intention to have it as parameter type. If it's designed to be passed around to functions I really don't want it to be an array. I am maintaining a legacy codebase where arrays are being used as hashmaps pretty much everywhere, and it's error prone. We lose all kinds of features like "find usages" and refactoring key/property names. Silly typos in array keys with no actual validation of any kind cause null values and annoying to find bugs. I agree that hashmaps can be really easy to use, but not as data structures outside of the function/method scope they were defined in. If value vs object semantics are important here, then something that is forward compatible with whatever structs may hold in the future could be interesting. --0000000000009ef019062f2fbbbd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Feb 28,= 2025 at 12:05=E2=80=AFAM Rob Landers <rob@bottled.codes> wrote:
<= /div>


On Thu, Feb= 27, 2025, at 22:01, Faizan Akram Dar wrote:
Hi,


On Thu, 27 Feb 2025, 20:55 Paul M. Jones, <pmjones@pmjones.io>= ; wrote:

> On F= eb 25, 2025, at 09:55, ignace nyamagana butera <nyamsprod@gm= ail.com> wrote:
>
> The problem= with your suggestion is that the specification from WHATWG and RFC3986/398= 7 are so different and that the function you are proposing won't be abl= e to cover the outcome correctly (ie give the developper all the needed inf= ormation). This is why, for instance, Mat=C3=A9 added the getRaw* method al= ongside the normalized getter (method without the Raw prefix).

The two functions need not return an identical array of = components; e.g., the 3986 parsing function might return an array much like= parse_url() does now, and the WHATWG function might return a completely di= fferent array of components (one that includes the normalized and/or raw co= mponents).

All of this is to say that the pa= rsing functionality does not have to be in an object to be useful *both* to= the internal API *and* to userland.




It most definitely needs to be an = object. Arrays are awful DX wise, there is array shape which modern IDEs li= ke phpstorm support and so does static analysis but the overall experience = remains subpar compared to classes (and objects).=C2=A0

I=E2=80=99m curious why you say this other tha= n an opinion about developer experience? Arrays are values, objects are not= . A parsed uri seems more like a value and less like an object. Just readin= g through the comments so far, it appears that whatever is used will just b= e wrapped in library code regardless, for userland code, but the objective = is to be useful for other extensions and core code. In that case, a hashmap= is much easier to work with than a class.

Loo= king at the objectives of the RFC and the comments here, it almost sounds l= ike it is begging to be a simple array instead of an object.=C2=A0

=E2=80=94 Rob<= br>

Depends on there bein= g the intention to have it as parameter type. If it's designed to be pa= ssed around to functions I really don't want it to be an array. I am ma= intaining a legacy codebase where arrays are being used as hashmaps pretty = much everywhere, and it's error=C2=A0prone. We lose all kinds of featur= es like "find usages" and refactoring key/property names. Silly t= ypos in array keys with no actual validation of any kind cause=C2=A0null va= lues and annoying to find bugs.

I agree that hashm= aps=C2=A0can be really easy to use, but not as data structures outside of t= he function/method scope they were defined in. If value vs object semantics= are important here, then something that is forward compatible with whateve= r structs may hold in the future could be interesting.

=

--0000000000009ef019062f2fbbbd--