Maybe it's a good idea to move them to another ext, and then move xmlparser back to PECL ?
2016-08-10 20:23 GMT+02:00 Christoph M. Becker <cmbecke...@gmx.de>: > On 10.08.2016 at 19:34, Fleshgrinder wrote: > > > 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. > > That might be a good idea, even if we already have the XMLReader. And > yes, the utf8_* functions don't really belong into ext/xml; frankly, I > think they don't belong anywhere – we already have iconv, mbstring and > recode which offer a subset of utf8_decode()/utf8_encode. OTOH, > utf8_decode()/_encode() appear to be often used (IIRC there are a lot of > user notes suggesting to use these functions). > > -- > Christoph M. Becker > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- pozdrawiam -- Michał Brzuchalski
