Re: Pre-RFC: Fixing spec bugs in the DOM extension
| From: | Niels Dossche | Date: | Fri, 29 Dec 2023 23:37:31 +0000 |
| Subject: | Re: Pre-RFC: Fixing spec bugs in the DOM extension | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-122064@lists.php.net to get a copy of this message | ||
Hi Gina
On 29/12/2023 15:40, G. P. B. wrote:
> Thank you for the work!
>
> I agree that making them proper classes instead of aliases is the better proposition here.
> I'm not fully informed about the DOM spec, and I don't know if the current
> class/interface hierarchy is in the best shape, but maybe we should also consider having a look a
> this?
>
Yeah, our current class hierarchy is wrong, but not "overly wrong". The incorrectness
comes from the design of the pre-HTML5 era.
This is how it's supposed to be:
CharacterData extends Node (Actually an interface, but PHP does not have interfaces with
properties)
Text extends CharacterData
CDATASection extends Text
ProcessingInstruction extends CharacterData
Comment extends CharacterData
However in the current implementation, the ProcessingInstruction class extends Node instead of
CharacterData.
Also CharacterData is a class instead of an interface in the current implementation.
So nothing too bad, but not correct either.
There's also some functionality that should be on the Element class instead of the Node class.
> About making those new classes finals, this would require reconsidering the class hierarchy
> anyway, as nearly everything inherits from DOMNode, and other classes (namely Comment/Text/CData
> nodes) extend other classes.
> However, I would not necessarily be against it, especially if we add the required interfaces,
> as the current mechanism of registering a custom class is not very powerful and rather cumbersome to
> use as the constructor is never called.
I'm already reconsidering the class hierarchy :-).
As for the constructor problem: I can fix that for the new classes, I can make sure the constructor
is called which would already solve a pain point.
> As such, I'm not sure if I would support adding the current mechanism to customize the
> node classes returned by the extension. Indeed, the current mechanism doesn't play nicely at
> all with static analysis and this is something I stopped trying to integrate when writing my DocBook
> renderer project. [1]
I'm also not entirely sure, but in the JS world we do have custom elements that you can
register and get an instance from back, so it has been done before at least.
>
> Best regards,
>
> Gina P. Banyard
>
> [1] https://gitlab.com/Girgias/docbook-renderer
> <https://gitlab.com/Girgias/docbook-renderer>
Kind regards
Niels