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