Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122188
Date: Fri, 19 Jan 2024 12:44:51 +0000
To: Niels Dossche <dossche.niels@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Message-ID: <juO__fN85fTu3on45Q2FvWNXjRImTLxzEYkOkX9JzmiRVtueHkWlIc2pINe_sO6LPdOYFF-2cgjvbbfsImBkX6kRE1swBaJoUVYHiJ8fiPc=@gpb.moe>
In-Reply-To: <921837a7-81bf-4c10-bb79-36eda76e8d5d@gmail.com>
References: <2006cef3-0e8c-49cc-9703-0fa70690a4ae@gmail.com> <lqcQzuiFsM5DUwmwevipw3GNQgEY03S0IOA7zT-FEh7OROFUZCY903C34kpOOTsPvLl1DgUix6MLWURPlpjLsgsoSD2WSRJBWH58Xsmk-lQ=@gpb.moe> <921837a7-81bf-4c10-bb79-36eda76e8d5d@gmail.com>
Feedback-ID: 96993444:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] [Discussion] Opt-in DOM spec-compliance
From: internals@gpb.moe ("Gina P. Banyard")

On Thursday, 18 January 2024 at 20:08, Niels Dossche <dossche.niels@gmail.c=
om> wrote:
> Hi Gina
>=20
> On 18/01/2024 14:05, Gina P. Banyard wrote:
>=20
> > Hello Niels,
> >=20
> > Thank you for the RFC and the thorough overview of the current state.
> >=20
> > I think converting the new aliases to proper classes which have the cor=
rect spec behaviour is indeed the way to proceed.
> >=20
> > I do have some questions however, do you really think we need the DOMDo=
cument methods to import modern nodes into legacy documents?
> > As I can imagine, this would provide fewer incentives for users to move=
 to the new spec compliant classes.
>=20
>=20
> It's a double-edged sword: if we don't provide it, it becomes harder to m=
igrate and it may take a longer time to do so.
> If we do provide it there may be fewer incentives.
>=20
> I think it's necessary as a first step to aid migration, otherwise, if we=
 don't provide this, it's going to become more difficult for library mainta=
iners as they'd have to effectively create two versions of their library in=
 some cases.
> By creating these methods it may become possible to use libraries that ar=
e not yet adapted to the new classes. So depending on your point of view it=
 may even accelerate adoption.
> One caveat is, as always, that any migration can be hindered if a library=
 you try to use relies on bugs that are fixed in the new classes.

Understandable, I suppose we can always deprecate the import modern node me=
thods before the import legacy nodes.

> > The other thing to clarify is why and when would those return false, co=
mpared to the methods that import legacy nodes which never throw?
> =20
> {import,adopt}ModernNode may return false or throw, depending on the $str=
ictErrorChecking property of DOMDocument, when an error occurs.
> The only possible error case really is when an unsupported node is import=
ed/adopted (e.g. a document itself).
> The reason we don't have the false return value for {import,adopt}LegacyN=
ode is because the DOM\{XML,HTML}Document class doesn't have a $strictError=
Checking property, i.e. it always uses exceptions.

ACK

Best regards,

Gina P. Banyard