ID: 49686
User updated by: galaxy4public+php at gmail dot com
Reported By: galaxy4public+php at gmail dot com
Status: Wont fix
Bug Type: Feature/Change Request
Operating System: Linux
PHP Version: 5.3.0
New Comment:
What really concerns me in regard to SPL as a static extension is that
many other extensions depends on it. For instance, with SPL statically
linked into PHP it's not possible to build the PCRE extension as shared,
and there more extensions which could have been dynamically built if SPL
was allowed to be "shared".
Consider the following scenario (we are currently running on our
servers): we have a shared hosting environment with hundreds of virtual
hosts and each additional unneeded extension consumes server's memory,
hence we provide a very basic PHP interpreter with no extensions loaded.
Then, users can load needed extensions vi their local php.ini or using
dl().
That's why I'm trying to convince you that making "extensions" to be
really extensions (i.e. dynamically loaded parts) is quite important.
Previous Comments:
------------------------------------------------------------------------
[2009-09-28 03:05:13] galaxy4public+php at gmail dot com
Actually the patch changes 2 lines in ext/array.c and makes it possible
to build SPL as a shared extension (all other code is already in place).
In 5.3.0 somebody removed a couple of configuration lines from
ext/spl/config.m4 and made it impossible to configure SPL with the
configure script. I believe that this was done due to the fact that
calls to SPL are all hardcoded dependencies.
Frankly, I don't understand why hardcode things when the mechanism for
dynamic loading is already here.
Instead of unconditionally rely on things like:
===
if (Z_OBJ_HT_P(array)->get_class_entry &&
instanceof_function(Z_OBJCE_P(array), spl_ce_Countable TSRMLS_CC)) {
===
why don't you use something like:
===
if (zend_hash_find(EG(class_table), "countable", sizeof("Countable"),
(void **) &pce) == SUCCESS) {
if (Z_OBJ_HT_P(array)->get_class_entry &&
instanceof_function(Z_OBJCE_P(array), *pce TSRMLS_CC)) {
===
Then, you can:
a) drop '#ifdef HAVE_SPL' around this blocks, since they will no longer
strictly depend on SPL;
b) it will be possible to build/load SPL dynamically (with no or little
effort)
Otherwise, what's the point of having "extensions" if they aren't
extensions but an integral part of the interpreter and can't be loaded
dynamically?
What really missing in PHP is a good extension dependency mechanism
(and, perhaps, auto extension loading), IMHO.
------------------------------------------------------------------------
[2009-09-27 19:57:39] [email protected]
I think we can safely reject the patch. Unless someone has a strong
argument to allow 5.2.12 to do not be forward compatible in some install
(as in not having spl enabled :).
------------------------------------------------------------------------
[2009-09-27 19:35:27] [email protected]
SPL is force enabled with PHP 5.3+ as static, so this patch really only
applies to 5.2 and I'm not sure if we're still open for new features.
------------------------------------------------------------------------
[2009-09-27 11:23:04] galaxy4public+php at gmail dot com
Well, I made the directory world-readable:
ftp://ftp.ru.openwall.com/pvt/galaxy/php-spl-shared/
I'll place any updates to the patch there (if there are any).
------------------------------------------------------------------------
[2009-09-27 10:37:23] galaxy4public+php at gmail dot com
Ouch, this line-wrapping feature really hurts! :( In the comment above
the link should be manually concatenated to get a correct URL.
------------------------------------------------------------------------
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/49686
--
Edit this bug report at http://bugs.php.net/?id=49686&edit=1
