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 > >
