Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:95073 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 16418 invoked from network); 12 Aug 2016 09:28:07 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 12 Aug 2016 09:28:07 -0000 X-Host-Fingerprint: 79.243.112.54 p4FF37036.dip0.t-ipconnect.de Received: from [79.243.112.54] ([79.243.112.54:15438] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 70/99-56950-2A69DA75 for ; Fri, 12 Aug 2016 05:28:05 -0400 To: internals@lists.php.net,Rowan Collins , internals@lists.php.net References: <9e9c440e-05d2-a452-556e-a6c62a9f195e@gmx.de> <208237ee-a22a-97b7-be63-f7cba986b137@fleshgrinder.com> <16fdbdc7-bad4-f978-32e9-e4bf7443e592@gmx.de> Message-ID: <5305f27a-08a1-2c46-9677-39298e22e445@arcor.de> Date: Fri, 12 Aug 2016 11:28:05 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Posted-By: 79.243.112.54 Subject: Re: [PHP-DEV] GC issue wrt. to resource <-> object cycles? From: cmbecker69@arcor.de ("Christoph M. Becker") 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