Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95033
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.45 as permitted sender)
To: internals@lists.php.net
References: <ed7bc05c-90a3-c21a-b43e-186221a73006@gmx.de>
 <CAF+90c9VBtbveOtbK7rRGAd+DJtq7dSzR4aYNo2q2vOs5624kQ@mail.gmail.com>
 <9e9c440e-05d2-a452-556e-a6c62a9f195e@gmx.de>
 <208237ee-a22a-97b7-be63-f7cba986b137@fleshgrinder.com>
 <16fdbdc7-bad4-f978-32e9-e4bf7443e592@gmx.de>
Message-ID: <a5504dbc-9e09-21fe-c472-24816bcd5ba1@gmail.com>
Date: Thu, 11 Aug 2016 11:04:57 +0100
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: <16fdbdc7-bad4-f978-32e9-e4bf7443e592@gmx.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] GC issue wrt. to resource <-> object cycles?
From: rowan.collins@gmail.com (Rowan Collins)

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]