On 12.02.2019 at 16:00, Nikita Popov wrote: > The ext/xml extension currently has GC issues, see > https://bugs.php.net/bug.php?id=76874. The tl;dr is that uses of xml_parser > will usually result in a cyclic structure, but resources do not support > cycle GC. This means that the user is required to take care of breaking GC > cycles manually, which is very unusual for PHP. > > I would like to port the xml extension from using a resources towards using > an object, which is fully GC integrated. This is implemented in > https://github.com/php/php-src/pull/3526. > > An XmlParser class is used instead of a resource. The class is final and > cannot be manually constructed. It is still used with the normal > xml_parser_* APIs. This is intended as an internal representation change, > not a conversion to OO APIs. The xml_parser_free() method becomes > effectively a no-op and may be deprecated in some future version. > > This change is intended for PHP 7.4. While it is technically BC breaking > (in that code that goes out of the way to use is_resource or similar may > break), but we've done a couple of these resource->object migration in > minor versions in the past (ref > https://wiki.php.net/rfc/operator_overloading_gmp and > https://wiki.php.net/rfc/hash-context.as-resource). > > Any thoughts?
I'm all for switching to objects in 7.4. I'm a bit concerned regarding the name of the new `XmlParser` class, though, since the xml_set_object() (a terrible API, by the way) example[1] uses exactly this class name, and there may be quite some code which followed suit. Maybe we should call the class `XMLPushParser`, although that would be inconsistent with functions like xml_parser_create(). [1] <http://php.net/manual/en/function.xml-set-object.php#refsect1-function.xml-set-object-examples> -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
