On 10/08/2016 19:23, Christoph M. Becker wrote:
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).
utf8_decode()/utf8_encode are, at best, extremely misleading names. Many uses of them in my experience go something like this: "I have an encoding problem, it's something to do with UTF-8, I'll try utf8_encode; hm, that didn't work, I'll try utf8_decode instead".
I hadn't even realised they're in the same extension as the equally misunderstood xml_parse_into_struct() which exposes a somewhat baffling intermediate parsing structure which is incredibly hard to work with. It mostly seems to be used to reinvent event-based parsing, which is already the main facility offered by that extension. (I just looked at the example on the manual page; it's bizarre.)
I'm not sure if we need yet another XML parsing extension, or just sign-post that we already have better ones for most tasks. Maybe XMLReader could be expanded to attach callbacks for passed nodes, and have a "readAll" method, so that it acted as an event-based parser?
Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
