Edit report at http://bugs.php.net/bug.php?id=53957&edit=1
ID: 53957
Comment by: landeholm at gmail dot com
Reported by: landeholm at gmail dot com
Summary: Unloading Extentions OR Overriding Native Functions
OR Importing Functions
Status: Wont fix
Type: Feature/Change Request
Package: Scripting Engine problem
Operating System: Irrelevant
PHP Version: 5.3.5
Block user comment: N
Private report: N
New Comment:
Thanks for your reply. Yes, I understand that it's unrealistic to expect
a feature that allows dynamic extension unloading. But how about
allowing function importing with the "use" statement? Regards~
Previous Comments:
------------------------------------------------------------------------
[2011-02-08 11:34:56] ras...@php.net
extension unloading on a per-request basis simply isn't feasible from a
performance point of view. And you obviously can't unload and leave it
unloaded
for the next request because that next request may be for a page that
expects the
extension to be there.
------------------------------------------------------------------------
[2011-02-08 11:27:16] landeholm at gmail dot com
Description:
------------
I'm building a framework which has a custom gettext implementation since
the gettext extension of PHP is poorly designed for my needs and it's
not installed in all environments so relying on it reduces
compatibility. The problem however is that it's installed in some
environments and since it claims the global "_" function which is pretty
much a gettext standard alias (and other gettext functions), it's
preventing me from implementing the gettext standard. There are no
possible way for me to solve this problem nicely today because PHP does
not have the ability to either:
A. Override/undeclare/rename native functions. (Okay, I can do it via
APD but that makes extension dependability even WORSE.)
B. Unloading extensions at runtime. (Most preferable... I don't want it
at all)
C. Importing functions. (My framework uses namespaces. The fact that
functions cannot be imported by the "use" keyword really spoils this
feature. Otherwise it could actually have fix this problem.)
Note that this problem assumes a context where you can't control the
environment in which you install your application in. This is a very
real scenario for a lot of people including me. This is a practical
problem, not a theoretical one.
Also note that declaring the "_" function in a namespace would be
pointless:
1. it would no longer be compatible with the gettext standard
2. it would require refactoring of all existing string wrapped code
3. it would no longer be compatible with existing string wrapped code
4. a longer name like \foo\translate_lib\_() defeats the point of having
a short function name
Another workaround is to declare a _ forwarding function in every
possible namespace, but that solution is dumb and ugly.
As a temporary workaround I might declare something like t\s() but I
don't like that solution and it doesn't solve 1, 2 and 3 above.
Test script:
---------------
/** EITHER A: */
undeclare_function("_");
/** OR B: */
unload_extension("gettext");
/** OR C: */
namespace foo;
use foo\translate_lib;
/** Test: */
// My gettext implementation.
function _($msgid) {
return translate($msgid);
}
echo _("hello");
Expected result:
----------------
bonjour
Actual result:
--------------
Fatal error: Cannot redeclare _()
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/bug.php?id=53957&edit=1
