On 8/10/2016 4:17 PM, Christoph M. Becker wrote: > On 10.08.2016 at 12:59, Nikita Popov wrote: > >> The simplest way to fix ext/xml in particular is probably to migrate it to >> use an object instead of a resource. > > I guess that is the best action in the long run (i.e. 7.2+), but that > would of course cause a BC break, so probably it's best to document that > the user has to break the cycle manually, if xml_set_object() is used > (7.0, 7.1). > > Wrt. to PHP 5.6 it appears there are no issues at all. While the code > out-commented by Thies is still there (which should be removed to avoid > further confusion), in the following a (shallow) copy of the object is > made, and apparently due to the additional refcount in the object store > of PHP 5, everything is okay. > > Another alternative for PHP 7.2 might be to drop (after deprecation) > xml_set_object(); actually, it seems to me this function is a relict of > pre PHP 5. Cf. example #1[1]. Instead of doing: > > xml_set_object($this->parser, $this); > xml_set_element_handler($this->parser, "tag_open", "tag_close"); > > one could simply do: > > xml_set_element_handler($this->parser, > [$this, "tag_open"], [$this, "tag_close]); > > [1] > <http://php.net/manual/en/function.xml-set-object.php#refsect1-function.xml-set-object-examples> >
It does not have to be a BC if we simply introduce a new API for this extension and keep the old one as is. The whole set of functions just cries out loud for a class that encapsulates the state of the parser and both the utf8_* functions simply do not belong in this extension. This new API can be introduced in any PHP minor along with a deprecation and removal (move to PECL and abandon) of the resource based things in PHP 8. -- Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
