Re: GC issue wrt. to resource <-> object cycles?
| From: | Christoph M. Becker | Date: | Wed, 10 Aug 2016 18:23:57 +0000 |
| Subject: | Re: GC issue wrt. to resource <-> object cycles? | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-95020@lists.php.net to get a copy of this message | ||
On 10.08.2016 at 19:34, Fleshgrinder wrote:
> On 8/10/2016 4:17 PM, Christoph M. Becker wrote:
>> On 10.08.2016 at 12:59, Nikita Popov wrote:
>>
>>> The simplest way to fix ext/xml in particular is probably to migrate it to
>>> use an object instead of a resource.
>>
>> I guess that is the best action in the long run (i.e. 7.2+), but that
>> would of course cause a BC break, so probably it's best to document that
>> the user has to break the cycle manually, if xml_set_object() is used
>> (7.0, 7.1).
>>
>> Wrt. to PHP 5.6 it appears there are no issues at all. While the code
>> out-commented by Thies is still there (which should be removed to avoid
>> further confusion), in the following a (shallow) copy of the object is
>> made, and apparently due to the additional refcount in the object store
>> of PHP 5, everything is okay.
>>
>> Another alternative for PHP 7.2 might be to drop (after deprecation)
>> xml_set_object(); actually, it seems to me this function is a relict of
>> pre PHP 5. Cf. example #1[1]. Instead of doing:
>>
>> xml_set_object($this->parser, $this);
>> xml_set_element_handler($this->parser, "tag_open", "tag_close");
>>
>> one could simply do:
>>
>> xml_set_element_handler($this->parser,
>> [$this, "tag_open"], [$this, "tag_close]);
>>
>> [1]
>>
>> <http://php.net/manual/en/function.xml-set-object.php#refsect1-function.xml-set-object-examples>
>
> It does not have to be a BC if we simply introduce a new API for this
> extension and keep the old one as is. The whole set of functions just
> cries out loud for a class that encapsulates the state of the parser and
> both the utf8_* functions simply do not belong in this extension.
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).
--
Christoph M. Becker