Re: Newcomer, PHP pre-processing, Magic Constants __FILE__ and __LINE__ override with #line like in C

> On 23 Oct 2022, at 20:43, Ludovic Pouzenc <ludovic@pouzenc.fr> wrote: > > Hi, > > I'm a newcomer here. I came from > https://wiki.php.net/rfc/howto. > > *TL;DR:* I want to know if a proposal of a #line parsing to alter __FILE__ and __LINE__ in PHP > like it exists in C could be a good idea. > > I've searched about __LINE__ and __FILE__ in mailing archives and wiki, I don't > really find things matching. I hope it's not because "__" are stripped before search. > "Magic constants" didn't help neither. Let me know if I am rethinking and old thing > already imagined here in the past. > > *Background / use case:* I think at first about webservices, maybe the useful also with > browser/human-facing use cases. > > With PHP, it's hard to get high responsiveness under load if user code start by loading a > composer's autoload.php, then (lazy) loads a whole framework with 10+ dependencies, then > execute 1 SQL request, 1 json_encode() then output and exit. Even with "Slim" framework > that should be minimal, using only the route feature, I see "strace" counting 200+ > file-related syscalls per request with recent linux/debian/apache/php-fpm. > > It's not so hard to get it better with other langages : when they are compiled, or when > framework loading happens at server start and to at each request. > > Web projects have more and more a "compilation" phase for minimising JS, for > proprocessing scss to css, it is possible to hook it some PHP processing too. > > In my university, I started using a purpose-written PHP Preprocessor to minimize runtime > dependency loading. It only understands #include like in C. From a > src/mywebservice/v1/some-endpoint.php it will generate and build/mywebservice/v1/some-endpoint.php > with all #include "some/path/somedep.php" replaced by the file's contents. > > So the generated some-endpoint.php have no run-time dependency at all: no autoload, no > include(), no require(). I think it evens maximize the gains with APC caching. > > The preprocessor also generate things like #line 2 "some/path/somedep.php" where an > #include was encountered, then a thing like #line 47 > "src/mywebservice/v1/some-endpoint.php" right after the end of the inclusion. In C, a > great concrete example of #line importance is working with a flex/bison parser generator. > > If PHP parser interpret #line as in C, __FILE__ and __LINE__ Magic Constants will be changed to > source file and line, instead of generated file and line. It could greatly improve development > write-then-rerun cycle. (missing ";" at line NN , other PHP Errors, Exception > details/traces) > > I hope it could unlock many use cases where "big" PHP frameworks get really hard time > to try to compete with other languages equivalents. > > Do you think it's an idea that is suitable to discuss, improve and submit as an RFC ? > > Regards, > > -- > > Ludovic Pouzenc > www.pouzenc.fr > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > Hi Ludovic, I can’t comment much on the actual change in the parser you’re asking about, but it sounds to me like preloading (https://www.php.net/manual/en/opcache.preloading.php <https://www.php.net/manual/en/opcache.preloading.php>, introduced via https://wiki.php.net/rfc/preload <https://wiki.php.net/rfc/preload>) might be a workable solution that’s already available? Cheers Stephen