Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121087
Message-ID: <4C6FD028-4E34-4578-AF04-EDAC120E3E94@koalephant.com>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_587284E7-F3F1-4AAD-9C5D-1BCDF2386BE5"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\))
Date: Mon, 18 Sep 2023 13:46:45 +0700
In-Reply-To: <29eb53a7-9aef-4e48-999e-97574f27a9df@gmail.com>
Cc: =?utf-8?Q?Alexandru_P=C4=83tr=C4=83nescu?= <drealecs@gmail.com>,
 PHP Internals <internals@lists.php.net>
To: Niels Dossche <dossche.niels@gmail.com>
References: <c7a7f77b-8187-23f7-7c02-c92f1b538039@gmail.com>
 <c774ef73-802b-42eb-9181-9a080713c390@gmail.com>
 <CAAwdEzCQps8+cFf86-6e_7gCXtdhG7DjLTyQ3TS-=3+kW-Pcqg@mail.gmail.com>
 <29eb53a7-9aef-4e48-999e-97574f27a9df@gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] DOM HTML5 parsing and serialization
 support
From: php-lists@koalephant.com (Stephen Reay)

--Apple-Mail=_587284E7-F3F1-4AAD-9C5D-1BCDF2386BE5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On 17 Sep 2023, at 18:28, Niels Dossche <dossche.niels@gmail.com> =
wrote:
>=20
> Hi Alexandru
>=20
> On 9/17/23 11:59, Alexandru P=C4=83tr=C4=83nescu wrote:
>> On Sat, Sep 16, 2023, 02:17 Niels Dossche <dossche.niels@gmail.com> =
wrote:
>>=20
>>>=20
>>> We'll add a common abstract base class DOM\Document (name taken from =
the
>>> DOM spec & Javascript world).
>>> DOM\Document contains the properties and abstract methods common to =
both
>>> HTML and XML documents.
>>>=20
>>>=20
>> Hi,
>>=20
>> Yes looks a lot better.
>> Great work overall! And thank you for taking on this effort.
>>=20
>> I would have a small suggestion: to make the abstract class an =
interface.
>> This will allow even more flexibility on how things can be build =
further,
>> suggesting composition over inheritance.
>> In user land we cannot have interfaces with properties (yet) but in =
php
>> internal interfaces we have example with interface UnitEnum that has =
name
>> property, extendes by BackedEnum that adds value property.
>>=20
>=20
> Right, we discussed the use of an interface internally too.
> Indeed as you suggest, we chose an abstract class over an interface =
because of the property limitation.
> Looking at UnitEnum & BackedEnum =
(https://github.com/php/php-src/blob/bae30682b896b26f177f83648bd58c77ba348=
0a8/Zend/zend_enum.stub.php) I don't see the properties defined on the =
interface. In practice, all enums get the properties of course, just not =
via the interface.
> So as we cannot represent the properties on the interfaces (yet), =
we'll stick with the abstract class for now.
>=20
>=20
>> Thank you,
>> Alex
>>=20
>=20
> Kind regards
> Niels
>=20
> --=20
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
Hi Niels,

Can you expand on the reasoning for two of the decisions in your =
proposal? I'm not sure I really see the reason/benefit :

1. fromX() methods are on the individual classes, rather than the =
parent, which as I understand it, you're using as a poor-mans interface =
with properties. I'd have thought that at the very least the parent =
should declare those methods as abstract


2. Why "fromEmptyDocument()" rather than just allowing `new =
DOM\{XML,HTML}Document` via a public constructor?

The only mention of 'constructor' I see in the email or the RFC is the =
line below:

> the properties set by DOMDocument's constructor are overridden by its =
load methods, which is surprising

But I don't really see how making the constructor private and forcing =
use of a static method changes this aspect, at all - it just introduces =
a different way to create an instance.


Otherwise, it's great to see some activity on DOM handling classes.


Cheers


Stephen=20


--Apple-Mail=_587284E7-F3F1-4AAD-9C5D-1BCDF2386BE5--