Re: GC issue wrt. to resource <-> object cycles?
| From: | Rowan Collins | Date: | Thu, 11 Aug 2016 10:04:57 +0000 |
| Subject: | Re: GC issue wrt. to resource <-> object cycles? | ||
| References: | 1 2 3 4 5 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-95033@lists.php.net to get a copy of this message | ||
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]