Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95074
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.17.20 as permitted sender)
To: Rowan Collins <rowan.collins@gmail.com>, 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>
 <a5504dbc-9e09-21fe-c472-24816bcd5ba1@gmail.com>
Message-ID: <d371a07e-b617-3fda-1f60-1c14efaa585b@gmx.de>
Date: Fri, 12 Aug 2016 11:30:25 +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: <a5504dbc-9e09-21fe-c472-24816bcd5ba1@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] GC issue wrt. to resource <-> object cycles?
From: cmbecker69@gmx.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
exist.

-- 
Christoph M. Becker