Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126484
Precedence: bulk
MIME-Version: 1.0
Date: Mon, 24 Feb 2025 10:15:01 +0100
To: "Gina P. Banyard" <internals@gpb.moe>
Cc: =?UTF-8?Q?M=C3=A1t=C3=A9_Kocsis?= <kocsismate90@gmail.com>, PHP
 Internals List <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API
In-Reply-To: <RYUX5rSGApW8lPGs1yovM2fIXXBHd_UcqEKAKgj8-dRrpThS4tC195Jb3kPTT5up96r7SZ2WunauAblAIEkZe41BwZxLeSE2SaKQLAYSmZo=@gpb.moe>
References: <CAH5C8xUb1O20ZDrOQNC=ckFxHUUWSK7sw_njQQzFBd0qgQqoww@mail.gmail.com>
 <RYUX5rSGApW8lPGs1yovM2fIXXBHd_UcqEKAKgj8-dRrpThS4tC195Jb3kPTT5up96r7SZ2WunauAblAIEkZe41BwZxLeSE2SaKQLAYSmZo=@gpb.moe>
Message-ID: <17bdbfa35c920a86a19690e356e05f99@bastelstu.be>
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

Hi

Am 2025-02-23 18:30, schrieb Gina P. Banyard:
> 2.
> I don't really understand how the UninitializedUriException exception 
> can be thrown?
> Is it somehow possible to create an instance of a URI without 
> initializing it?

It's mentioned in the RFC (it was not yet, when I read through the RFC):

> This can happen for example when the object is instantiated via 
> ReflectionClass::newInstanceWithoutConstructor()).

Incidentally this is *also* something that would be fixed by making the 
classes `final`, since it's illegal to bypass the constructor for final 
internal classes:

     <?php

     $r = new ReflectionClass(Random\Engine\Mt19937::class);
     $r->newInstanceWithoutConstructor();

results in:


     Fatal error: Uncaught ReflectionException: Class 
Random\Engine\Mt19937 is an internal class marked as final that cannot 
be instantiated without invoking its constructor

> This seems unwise in general.

I agree. This exception is not really actionable by the user and more of 
a “should never happen” case. It should be prevented from appearing.

The same is true for `UriOperationException`. The RFC says that it can 
happen for memory issues. Can this actually happen? My understanding is 
that the engine bails out when an allocation fails. In any case if a 
more graceful handling is desired it should be some generic 
`OutOfMemoryError` rather than an extension-specific exception.

With regard to unserialization, let me refer to: 
https://externals.io/message/118311. ext/random uses `\Exception` and I 
suggest ext/uri to do the same. This should also be handled in a 
consistent way across extensions, e.g. by reproposing 
https://wiki.php.net/rfc/improve_unserialize_error_handling.

And with “Theoretically, URI component reading may also trigger this 
exception” being a theoretical issue only, the `UriOperationException` 
is not actually necessary at all.

> 3.
> I'm not really convinced by using the constructor to be able to create 
> a URI object.
> I think it would be better for it to be private/throwing and have two 
> static constructor `parse` and `tryParse`,
> mimicking the API that exists for creating an instance of a backed enum 
> from a scalar.

enums are little different in that they are a singleton. The 
Dom\HTMLDocument class with only named constructors might be a better 
comparison. But I don't have a strong opinion on constructor vs named 
constructor here.

Best regards
Tim Düsterhus