Re: [RFC] [Discussion] DOM HTML5 parsing and serialization support

> On 17 Sep 2023, at 18:28, Niels Dossche <dossche.niels@gmail.com> wrote: > > Hi Alexandru > > On 9/17/23 11:59, Alexandru Pătrănescu wrote: >> On Sat, Sep 16, 2023, 02:17 Niels Dossche <dossche.niels@gmail.com> wrote: >> >>> >>> 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. >>> >>> >> Hi, >> >> Yes looks a lot better. >> Great work overall! And thank you for taking on this effort. >> >> 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. >> > > 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/bae30682b896b26f177f83648bd58c77ba3480a8/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. > > >> Thank you, >> Alex >> > > Kind regards > Niels > > -- > 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