FAST_ZPP is here to stay , see the discussion
https://externals.io/thread/200

And fallback code elimination
https://github.com/php/php-src/pull/2118

On Tue, Apr 25, 2017 at 6:20 PM, Martin "eto" Misuth <et.c...@ethome.sk>
wrote:

> Username: eto
>
> Hello, after lot of pondering, I finally decided to register to mailing
> list
> & wiki. Reading wiki registration page, I am supposed to announce my
> registration here.
>
> I registered mainly for (possible) RFC proposals (none prepared yet) and
> to ask some questions about php codebase - using more lasting medium
> than irc is.
>
> I am sysadmin/PHP "developer" from Slovak Republic with focus on php
> "services" (aka daemons), php backends and such. My main php related
> timesink currently is messing with PHP 7.1.
>
> For few years now, I have been experimenting with extension writing, some
> of
> which I deployed internally. Being sysadmin I am not entirely confident
> with my
> code yet, but I plan to share most of my stuff eventually.
>
> Before that though, I would like to produce few microscopic patches to
> normal php distribution, to ease some miniscule pain points I am
> constantly hitting.
>
> For that, I would first like to ask clarification about FAST_ZPP maco "API"
> from Dmitry Stogov & Bob Weinand.
>
> In my extensions/experiments I am using solely this API for accessing
> php:function() call parameters, not providing any "fallback"
> through zend_parse_parameters() when #ifndef FAST_ZPP.
>
> Skimming through codebase, it seems that few, 'often called', functions
> were
> converted into FZPP style, but they still preserve 'legacy parsing style'
> implemented as well.
>
> Let's say, depending on how my currents attempts end up working, I want to
> modify few bundled extension functions, is it okay to rewrite them to use
> solely FAST_ZPP?
>
> Or does have zend_parse_parameters() codepath to be preserved for years to
> come?
>
>   eto
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Reply via email to