ID: 45421
User updated by: rpeters at icomproductions dot ca
Reported By: rpeters at icomproductions dot ca
Status: Bogus
Bug Type: Feature/Change Request
Operating System: CentOS 4.3
PHP Version: 5.2.6
New Comment:
So if I want this request re-examined, what do I need to do?
I think the support of opcode caches should be of importance to PHP
devs and users alike, and want to ensure this gets a fair examination
rather than being dismissed out of hand like it has been so far.
Previous Comments:
------------------------------------------------------------------------
[2008-07-09 15:29:27] rpeters at icomproductions dot ca
Since this has not received comment, I take this to mean that the PHP
developers do not care that their design choices make it impossible to
cache some PHP applications, even though they were designed using
recommended features that have no alternatives (like __DIR__).
I would have thought that ensuring there was an efficient way to cache
PHP applications, and thereby improve PHP's performance, would have a
high priority, and not be considered "bogus". I'm saddened to learn
otherwise.
------------------------------------------------------------------------
[2008-07-02 23:03:32] rpeters at icomproductions dot ca
The problem is not in the cache, as they see it. The problem is that
__FILE__ BECOMES opcode, rather than being evaluated at runtime as
needed due to hardlinks. They are simply caching the opcode that PHP
provides.
This seems reasonable to me as well, except for the fact that __FILE__
becomes unusable if it's cached. It's unreasonable for an opcache to
parse the PHP file for use of __FILE__ due to performance reasons, so
I'm asking PHP to play nice by providing a feature that will allow the
opcache to perform efficiently, while maintaining needed PHP
functionality.
Or, alternatively, to clean up the opcodes provided to the caches
(xCache, eAccelerator, etc all suffer from this issue) so that __FILE__
isn't evaluated until after the opcode is generated.
------------------------------------------------------------------------
[2008-07-02 22:56:50] scott...@php.net
realpath($_SERVER['PHP_SELF']) but that's mainly for the executing
file.
You're asking us to add a feature for what is essentially a problem
with the opcode cache, there is no problem with PHP in this case.
------------------------------------------------------------------------
[2008-07-02 22:08:28] rpeters at icomproductions dot ca
I would love to stop "relying on __FILE__", which is why I introduced
this feature request...???
If you have an existing way of finding the containing directory of a
file being run via an include (as desired in the example code) that does
not rely on __FILE__, please provide it, none of the documentation or
attached comments suggest any alternatives, and in fact strongly
recommend using __FILE__.
In my application, we have one file included from all others, in many
different directories, making the working directory rather random, and
unrelated to the containing directory of the centralized file, so
__FILE__ and/or a runtime equivalent are necessary.
------------------------------------------------------------------------
[2008-07-02 22:00:29] scott...@php.net
There is nothing wrong with PHP here, its working as intended. I
suggest you stop relying on __FILE__ if you intend to use an opcode
cache.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/45421
--
Edit this bug report at http://bugs.php.net/?id=45421&edit=1
