Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126850
Content-Type: multipart/alternative;
 boundary="------------AnfSM5bLF7xH5RbQiVZR8VOz"
Message-ID: <2e95e8fe-7cf0-493f-bd0a-9fff0956baaa@gmail.com>
Date: Wed, 19 Mar 2025 22:18:24 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API
To: =?UTF-8?B?TcOhdMOpIEtvY3Npcw==?= <kocsismate90@gmail.com>
Cc: PHP Internals List <internals@lists.php.net>
References: <CAH5C8xUb1O20ZDrOQNC=ckFxHUUWSK7sw_njQQzFBd0qgQqoww@mail.gmail.com>
 <dd61999c-1ebd-4765-9add-cd8065968965@gmail.com>
 <CAOV5rgYZ_s1of-igLFEK7oqqh6=3HeYv0=JvvKvvjkcp0F6Q9Q@mail.gmail.com>
 <CAH5C8xV67frqOBCvLt73RM7QO86_pu40sHP5h71_kDRbKPtA8Q@mail.gmail.com>
 <1BCB4144-231D-45EA-A914-98EE8F0F503A@automattic.com>
 <8E614C9C-BA85-45D8-9A4E-A30D69981C5D@automattic.com>
 <CAH5C8xV69pHnSKWJrVB8EQab7vPhcaXAwYezoG6z3Oj7ZkXBaQ@mail.gmail.com>
 <bc5472e39bc607e2c7accc9d2bd6f239@bastelstu.be>
 <9bf11a89-39d9-457b-b0ea-789fd07d7370@gmail.com>
 <CAH5C8xWnoytE=jm1sxr-HcSZFzmG8SrzghinmBZa-QyGqN4uUg@mail.gmail.com>
 <6430b9ed-638d-4247-9fa9-d1a9148c382b@gmail.com>
 <CAH5C8xX3tCS3B3z2YFbRudCXi=ZNHE0scrmoFO7cXxU773EfpA@mail.gmail.com>
Content-Language: fr
In-Reply-To: <CAH5C8xX3tCS3B3z2YFbRudCXi=ZNHE0scrmoFO7cXxU773EfpA@mail.gmail.com>
From: nyamsprod@gmail.com (Ignace Nyamagana Butera)

This is a multi-part message in MIME format.
--------------AnfSM5bLF7xH5RbQiVZR8VOz
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


On 17/03/2025 20:58, Máté Kocsis wrote:
> Hi Ignace,
>
>     1) around `Uri\UninitializedUriException` If I look at the
>     behaviour of
>     `DatetimeImmutable` in the same scenario or a Userland object
>     instead of
>     throwing an exception an error is thrown
>
>     see:
>
>     - https://3v4l.org/d4VrY
>     - https://3v4l.org/Wn7En
>
>     Shouldn't the URI feature follow the same path for consistency ?
>     Instead
>     of throwing an exception it should throw an Error on uninitialized
>     issue
>     at least.
>
>
> Yes, you are right! Uri\UninitializedUriException should extend an 
> Error indeed,
> since people shouldn't try to catch it either.
>
>
>     2) around Normalization. In case of query normalization, sorting the
>     query string is not mention does it means that with the current
>     feature
>
>     `http://example.com?foo=bar&foo=rab`
>     <http://example.com?foo=bar&foo=rab>
>     is different from
>     `http://example.com?foo=rab&foo=bar`
>     <http://example.com?foo=rab&foo=bar>
>
>
> Yes, that's the case, this feature is not implemented. As far as I see 
> though, it's better
> not to change the order of query parameters, especially the order of 
> duplicated
> parameters in order not to accidentally change the intended meaning of 
> the query string.
> What's your stance here?
>
> Máté
>
>
Hi Maté,

Thanks for the clarifications, I ask for the latter because I am trying 
to create a polyfill using league/uri-interfaces so

my questions come essentially from me trying to create the correct 
polyfill to better understand the new class (specifically,

the RFC3986 Uri). You can find the ongoing work here if you want to see

https://github.com/bakame-php/aide-uri/blob/main/src/Uri.php

While implementing the polyfill I am finding easier DX wise to make the 
constructor private and use instead named constructors for 
instantiation. I would be in favor of

`Uri::parse` and `Uri::tryParse` like it is done currently with Enum and 
the `from` and `tryfrom` named constructors.

My reasoning is as follow:

  there's no right way or wrong way to instantiate an URI there are only 
contexts. While the parse method is all about parsing a string, one 
could legitimately use other named constructors like 
`Uri::fromComponents` which would take for instance the result of 
parse_url to build a new URI. This can become handy in the case of 
RFC3986 URI if you need to create an new URI not related to the http 
scheme and that do not use all the components like the email, data or 
FTP schemes.

  By allowing creating URI based on their respective components value 
you make it easier for dev to use the class. Also this means that if we 
want to have a balance API then a `toComponents` method should come hand 
in hand with the named constructor.

I would understand if that idea to add both components related methods 
is rejected, they could be implemented on userland, but the main point 
was to prove that from the VO or the developer POV in absence of a 
clearly defined instantiation process, having a traditional constructor 
fails to convey all the different way to create an URI.

--------------AnfSM5bLF7xH5RbQiVZR8VOz
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 17/03/2025 20:58, Máté Kocsis wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAH5C8xX3tCS3B3z2YFbRudCXi=ZNHE0scrmoFO7cXxU773EfpA@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div class="gmail_quote gmail_quote_container">
          <div>Hi Ignace,</div>
          <div><br>
          </div>
          <blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(77,77,77);padding-left:1ex">
            1) around `Uri\UninitializedUriException` If I look at the
            behaviour of <br>
            `DatetimeImmutable` in the same scenario or a Userland
            object instead of <br>
            throwing an exception an error is thrown<br>
            <br>
            see:<br>
            <br>
            - <a href="https://3v4l.org/d4VrY" rel="noreferrer"
              target="_blank" moz-do-not-send="true"
              class="moz-txt-link-freetext">https://3v4l.org/d4VrY</a><br>
            - <a href="https://3v4l.org/Wn7En" rel="noreferrer"
              target="_blank" moz-do-not-send="true"
              class="moz-txt-link-freetext">https://3v4l.org/Wn7En</a><br>
            <br>
            Shouldn't the URI feature follow the same path for
            consistency ? Instead <br>
            of throwing an exception it should throw an Error on
            uninitialized issue<br>
            at least.<br>
          </blockquote>
          <div><br>
          </div>
          <div>Yes, you are right! <span style="color:rgb(191,191,191)">Uri\UninitializedUriException
              should extend an Error indeed,</span></div>
          <div><span style="color:rgb(191,191,191)">since people
              shouldn't try to catch it either.</span></div>
          <div> </div>
          <blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(77,77,77);padding-left:1ex">
            <br>
            2) around Normalization. In case of query normalization,
            sorting the <br>
            query string is not mention does it means that with the
            current feature<br>
            <br>
            `<a href="http://example.com?foo=bar&amp;foo=rab"
              rel="noreferrer" target="_blank" moz-do-not-send="true">http://example.com?foo=bar&amp;foo=rab`</a><br>
            is different from<br>
            `<a href="http://example.com?foo=rab&amp;foo=bar"
              rel="noreferrer" target="_blank" moz-do-not-send="true">http://example.com?foo=rab&amp;foo=bar`</a><br>
            <br>
          </blockquote>
          <div><br>
          </div>
          <div>Yes, that's the case, this feature is not implemented. As
            far as I see though, it's better</div>
          <div><span style="color:rgb(191,191,191)">not to change </span><span
              style="color:rgb(191,191,191)">the order of query
              parameters, especially the order of duplicated</span></div>
          <div><span style="color:rgb(191,191,191)">parameters in order
              not to accidentally change the intended meaning of the
              query string</span><span style="color:rgb(191,191,191)">.</span></div>
          <div><span style="color:rgb(191,191,191)">What's your stance
              here?</span></div>
          <div><br>
          </div>
          <div><span style="color:rgb(191,191,191)">Máté</span></div>
          <div><br>
          </div>
          <div><br>
          </div>
        </div>
      </div>
    </blockquote>
    <p>Hi Maté,</p>
    <p>Thanks for the clarifications, I ask for the latter because I am
      trying to create a polyfill using league/uri-interfaces so</p>
    <p>my questions come essentially from me trying to create the
      correct polyfill to better understand the new class (specifically,</p>
    <p>the RFC3986 Uri). You can find the ongoing work here if you want
      to see </p>
    <p><a class="moz-txt-link-freetext" href="https://github.com/bakame-php/aide-uri/blob/main/src/Uri.php">https://github.com/bakame-php/aide-uri/blob/main/src/Uri.php</a> <br>
    </p>
    <p>While implementing the polyfill I am finding easier DX wise to
      make the constructor private and use instead named constructors
      for instantiation. I would be in favor of </p>
    <p>`Uri::parse` and `Uri::tryParse` like it is done currently with
      Enum and the `from` and `tryfrom` named constructors.<br>
    </p>
    <p>My reasoning is as follow:</p>
    <p> there's no right way or wrong way to instantiate an URI there
      are only contexts. While the parse method is all about parsing a
      string, one could legitimately use other named constructors like
      `Uri::fromComponents` which would take for instance the result of
      parse_url to build a new URI. This can become handy in the case of
      RFC3986 URI if you need to create an new URI not related to the
      http scheme and that do not use all the components like the email,
      data or FTP schemes.</p>
    <p> By allowing creating URI based on their respective components
      value you make it easier for dev to use the class. Also this means
      that if we want to have a balance API then a `toComponents` method
      should come hand in hand with the named constructor.</p>
    <p>I would understand if that idea to add both components related
      methods is rejected, they could be implemented on userland, but
      the main point was to prove that from the VO or the developer POV
      in absence of a clearly defined instantiation process, having a
      traditional constructor fails to convey all the different way to
      create an URI.</p>
  </body>
</html>

--------------AnfSM5bLF7xH5RbQiVZR8VOz--