On 28/01/15 21:32, Stanislav Malyshev wrote:
> Hi!
> 
>> Some feedback: I feel the RFC is not clear about the advantages and
>> disadvantages of including this package. Mostly, the RFC is "hey I have
>> this package can we include it in core?" I feel like it's fairly incomplete
> 
> Agreed. There needs to be some work done on explaining why we need to
> include this in core, not just "ok, here's a bag of bits, do you want
> it?" Maybe we do, maybe we don't - but please, help us decide that! I'd
> like the RFC to clearly explain what the new extension does better and
> why.
> 
> Also, I see in the docs (which will need to be converted to docbook if
> it is added, btw) this:
> 
> This extension unconditionally depends on the pre-loaded presence of the
> following PHP extensions:
> 
> raphf
> propro
> spl
> 
> SPL is fine, but what's with the other two? Are they to be merged into
> core too? The RFC does not mention them and they seem to be some
> unrelated things which I personally have no idea about.

It was in the RFC, but they obviously vanished in the last edit...

I explained that in another mail and will put it (amongst a lot of other
things that came up during this thread) into the RFC:

---8<---
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
handle API is in main and the property proxy API is in ext/standard.

The resource factory and persistent handle API provides a similar but
extended set of functionality of what zend_list provides.

ZE2 compatible docs can currently be found here:
http://php.github.io/pecl-php-raphf/php__raphf_8h.html

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.

ZE2 compatible docs can currently be found here:
http://php.github.io/pecl-php-propro/php__propro_8h.html
--->8---

> 
> In general, I'd love to have great HTTP support in core, but let's do it
> right. The more time you as RFC author spend now on explaining why this
> ext is great, the more tools we'll have if it's accepted to get users to
> actually use it, and that's the ultimate point of it. Without it, we
> don't have adequate tools to make a decision and to support the users
> after the decision if it's positive.
> 

I'm a bad sales person, but I'll try better.


-- 
Regards,
Mike

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to