Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [rfc:direct-execution-opcode] Whether need __FILE__ the value of the file to replace the compiled opcode file path »

[rfc:direct-execution-opcode] Whether need __FILE__ the value of the file to replace the compiled opcode file path

php.internals

€– ”k”k

5 years ago
Magic constant __FILE__ and __DIR__ of values is source code path, whether need replace to opcdoe file path at compile time RFC see : https://wiki.php.net/rfc/direct-execution-opcode

A.L.E.C

5 years ago
On 10.12.2020 13:46, €– ”k”k wrote:
> Magic constant __FILE__ and __DIR__ of values is source code path, whether need replace to opcdoe file path at compile time > > RFC see : https://wiki.php.net/rfc/direct-execution-opcode
That's not my field of expertise, so I can't say much about the idea. But this need to be redacted, because in the current form it's really hard to read.
-- Aleksander Machniak Kolab Groupware Developer [https://kolab.org] Roundcube Webmail Developer [https://roundcube.net] ---------------------------------------------------- PGP: 19359DC1 # Blog: https://kolabian.wordpress.com

€– ”k”k

5 years ago
Hi, Aleksander Machniak: which part is more difficult to read? Can you tell me? ________________________________ 发件人: Aleksander Machniak <alec@alec.pl> 发送时间: 2020年12月10日 20:53 收件人: internals@lists.php.net <internals@lists.php.net> 主题: Re: [PHP-DEV] [rfc:direct-execution-opcode] Whether need __FILE__ the value of the file to replace the compiled opcode file path On 10.12.2020 13:46, €– ”k”k wrote:
> Magic constant __FILE__ and __DIR__ of values is source code path, whether need replace to opcdoe file path at compile time > > RFC see : https://wiki.php.net/rfc/direct-execution-opcode
That's not my field of expertise, so I can't say much about the idea. But this need to be redacted, because in the current form it's really hard to read.
-- Aleksander Machniak Kolab Groupware Developer [https://kolab.org] Roundcube Webmail Developer [https://roundcube.net] ---------------------------------------------------- PGP: 19359DC1 # Blog: https://kolabian.wordpress.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php

Sara Golemon

5 years ago
On Thu, Dec 10, 2020 at 8:40 AM €– ”k”k <chopins.xiao@gmail.com> wrote:
> Hi, Aleksander Machniak: > which part is more difficult to read? Can you tell me? > >
All of it. I'm sorry, but I have absolutely no idea what you're trying to propose here. Something about __FILE__ not being the right value in certain circumstances because of something about opcache. -Sara

Morgan Breden

5 years ago
I'm not 100% certain but I believe what chopins is proposing is the ability to require()/include() files generated by opcache, without including the .php file. The reference to __FILE__ is I believe a warning to using relative paths, since the compiled opcode file would be in a different location? On Thu, Dec 10, 2020 at 10:52 AM Sara Golemon <pollita@php.net> wrote:

Sara Golemon

5 years ago
On Thu, Dec 10, 2020 at 2:20 PM Morgan Breden <morganbreden@gmail.com> wrote:
> I'm not 100% certain but I believe what chopins is proposing is the > ability to require()/include() files generated by opcache, without > including the .php file. > > The reference to __FILE__ is I believe a warning to using relative paths, > since the compiled opcode file would be in a different location? >
Yeah, I found their PR which made the intent a lot clearer. I would add this to the already sizable list of reasons why that PR isn't a good idea. -Sara

tyson andre

5 years ago
Hi Chopins Xiao, Some comments on https://wiki.php.net/rfc/direct-execution-opcode 1) This should be marked as "Status: Under Discussion" in the RFC document itself, not draft? 2) https://wiki.php.net/rfc/howto states: > 5. Listen to the feedback, and try to answer/resolve all questions. > **Update your RFC to document all the issues and discussions. > Cover both the positive and negative arguments.** Put the RFC URL into all your replies. The RFC guidelines mention this should document the negative arguments, e.g. as a Discussion section with quotes of the negative arguments (arguments against the RFC) and positive arguments. I'd recommend linking to the discussions on the mailing list, as there had been a lot of discussion there, e.g. as a References section at the end of the document https://externals.io/message/112482 and https://externals.io/message/111965 and https://externals.io/message/111979 ---- https://wiki.php.net/rfc/direct-execution-opcode#backward_incompatible_changes was also unclear to me > Magic constant `__FILE__` is the absolute path to the compiled source file, not the path to the opcode file that is currently executing "to the compiled source file" should be clarified to say something like "to the compiled source file for the packager (not the end user)" (e.g. `require_once __DIR__ . '/other.php'` would get converted to the opcode `INCLUDE_OR_EVAL (require_once) string("/home/packagerusername/other.php")` even with optimizations disabled, which would be unexpected for the packager and the end user) I don't think there are any problems with `__LINE__`, that's the line number within the file, and is unchanged by the path to the file. Regards, - Tyson

€– ”k”k

5 years ago
Thanks Tyson for pointed out the problem I will change the RFC status to "Under Discussion". The answer is unified here: 1. Default, different versions of opcode files are prohibited from being executed. 2. The __FILE__ , __DIR__ and other PHP's constant is like C Macro. When compiled, they are replaced with actual values. In php, It will be replaced when compiled into opcode. so opcode file will store the absolute path to the currently compiled PHP file(Compile time). All platform-related constant values are replaced with values related to the current compilation environment Regards ________________________________ 发件人: tyson andre <tysonandre775@hotmail.com> 发送时间: 2020年12月13日 0:50 收件人: €– ”k”k <chopins.xiao@gmail.com>; internals@lists.php.net <internals@lists.php.net> 主题: Re: [rfc:direct-execution-opcode] Whether need __FILE__ the value of the file to replace the compiled opcode file path Hi Chopins Xiao, Some comments on https://wiki.php.net/rfc/direct-execution-opcode 1) This should be marked as "Status: Under Discussion" in the RFC document itself, not draft? 2) https://wiki.php.net/rfc/howto states:
> 5. Listen to the feedback, and try to answer/resolve all questions. > **Update your RFC to document all the issues and discussions. > Cover both the positive and negative arguments.** Put the RFC URL into all your replies.
The RFC guidelines mention this should document the negative arguments, e.g. as a Discussion section with quotes of the negative arguments (arguments against the RFC) and positive arguments. I'd recommend linking to the discussions on the mailing list, as there had been a lot of discussion there, e.g. as a References section at the end of the document https://externals.io/message/112482 and https://externals.io/message/111965 and https://externals.io/message/111979 ---- https://wiki.php.net/rfc/direct-execution-opcode#backward_incompatible_changes was also unclear to me
> Magic constant `__FILE__` is the absolute path to the compiled source file, not the path to the opcode file that is currently executing
"to the compiled source file" should be clarified to say something like "to the compiled source file for the packager (not the end user)" (e.g. `require_once __DIR__ . '/other.php'` would get converted to the opcode `INCLUDE_OR_EVAL (require_once) string("/home/packagerusername/other.php")` even with optimizations disabled, which would be unexpected for the packager and the end user) I don't think there are any problems with `__LINE__`, that's the line number within the file, and is unchanged by the path to the file. Regards, - Tyson