Re: GC issue wrt. to resource <-> object cycles?

On 11.08.2016 at 12:04, Rowan Collins wrote: > 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". You're dead on, AFAICT. > 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.) xml_parse_into_struct() is, in my opinion, also a legacy to better get rid of; we have DOM and SimpleXML for this. > 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? I wouldn't add that to XMLReader, but rather introduce a new abstract class, say SAXParser. I don't mind in which extension this class would live. -- Christoph M. Becker