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
