Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81338
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.45 as permitted sender)
Message-ID: <54C94B11.2060104@gmail.com>
Date: Wed, 28 Jan 2015 12:48:17 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Michael Wallner <mike@php.net>, Nikita Popov <nikita.ppv@gmail.com>
CC: PHP Internals <internals@lists.php.net>
References: <54C8D36E.7010803@php.net> <CAF+90c98Mrj17p7ZPc=0eAYyt01-8rCpSBX9wRrKPKFO+gdZTg@mail.gmail.com> <54C92DE9.8010200@php.net>
In-Reply-To: <54C92DE9.8010200@php.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] [VOTE] pecl_http
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> As stated in one of the discussion threads, those dependencies could be
> merged to main/ and/or ext/standard. In the current patch the persistent

This should be prominently part of the RFC, not buried in the threads.
Merging two extensions into ext/standard is not some tiny detail that
nobody cares about, it's putting stuff into PHP core that has to be
supported and accounted for by everybody.

> The resource factory and persistent handle API provides a similar but
> extended set of functionality of what zend_list provides.

Extended in which way? Why zend_list is not enough? Why it is preferable
to use this new extension to improving zend_list?

> The property proxy handles R/W access to object properties that
> represent C struct members. Similar functionality was supposed to be in
> ZE2, but disfunctional to my findings.

Why it is "disfunctional" and which findings prove it? ZE objects has a
number of handlers, why it is not enough to use them? Which capabilities
the new extension adds that did not exist before? Why it is preferable
to add new API to the core to extending existing APIs to support needed
use-cases?

I think the fact that the RFC fails to mention that this is also vote
for introducing two new APIs into the core, which have no direct
relation to HTTP, is a pretty big defect. I understand it is not
intentional, but voting on this RFC without clear realization that the
vote is actually on three things, two of which are core API
modifications and never mentioned in the RFC itself, is just wrong and
such RFC should have never been put to vote.

I understand making these two extensions clear puts an additional burden
on the RFC author, but that is what putting things into core involves,
especially thing that is this big - once it is in the core, everybody
shares the responsibility for it, especially the main/ parts which are
not something you can dismiss as private matter for the extension.

-- 
Stas Malyshev
smalyshev@gmail.com