Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
[Walter Franzini [EMAIL PROTECTED]] [sorry, my English is bad] Zeev Suraski [EMAIL PROTECTED] writes: [...] Why? Whatever extension you use on your box, put them in the php.ini. dl() is never a better option. Zeev An example not solvable using php.ini: At SysNet, we access dbms only with odbc_* functions using (for different apps on the same server) solid and IBMdb2. We compile ext/odbc/php_odbc.c as solid.so and ibmdb2.so and load the right module using dl (). Using php.ini is not feasible because this lead to multiple function definition. I think a similar situation may arise with multiple xslt backend, they must export the same API but could provide different features (or bugs) so you must use xslt1 for app1 and xslt2 for app2. Please don't drop dl () :-) Shane Caraveo did some work on the ODBC module to solve this once, by using macros for all potentially clashing symbols in the ext/odbc source. It's not there anymore though, and that's mostly my fault. I guess we could go back to that model. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
At 11:37 28-08-01, Walter Franzini wrote: [sorry, my English is bad] Zeev Suraski [EMAIL PROTECTED] writes: [...] Why? Whatever extension you use on your box, put them in the php.ini. dl() is never a better option. Zeev An example not solvable using php.ini: At SysNet, we access dbms only with odbc_* functions using (for different apps on the same server) solid and IBMdb2. We compile ext/odbc/php_odbc.c as solid.so and ibmdb2.so and load the right module using dl (). Using php.ini is not feasible because this lead to multiple function definition. I think a similar situation may arise with multiple xslt backend, they must export the same API but could provide different features (or bugs) so you must use xslt1 for app1 and xslt2 for app2. Please don't drop dl () :-) We're not dropping it :) It works just as well as it did until now, which is not too well. Solving the problems that arise by deprecating dl() (improving the ODBC module, for instance) are much easier than solving the problems that fixing the broken things about dl(). Right now, we're simply keeping the status-quo. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
[Zeev Suraski [EMAIL PROTECTED]] At 17:55 07-08-01, Stig Sæther Bakken wrote: Now we're talking! I assume it is not straightforward, what are the technical challenges in doing JIT module initialization? It's not much of a challenge really. If we decide it should be done, it can be done... Ok, so it's just a matter of minit_done and rinit_done properties for each module? Let's go for that, and either keep dl() or replace it with php_load_extension() (the difference being that the latter knows what file extension to use on your platform). - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
On Wed, Aug 08, 2001 at 09:28:02AM +0200, Stig Sæther Bakken wrote: [Zeev Suraski [EMAIL PROTECTED]] At 17:55 07-08-01, Stig Sæther Bakken wrote: Now we're talking! I assume it is not straightforward, what are the technical challenges in doing JIT module initialization? It's not much of a challenge really. If we decide it should be done, it can be done... Ok, so it's just a matter of minit_done and rinit_done properties for each module? Let's go for that, and either keep dl() or replace it with php_load_extension() (the difference being that the latter knows what file extension to use on your platform). sascha had a patch for this some time ago - the gain was near to zero. this might make sense once we hit the few hundred extension border... tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
At 10:39 08-08-01, Thies C. Arntzen wrote: On Wed, Aug 08, 2001 at 09:28:02AM +0200, Stig Sæther Bakken wrote: [Zeev Suraski [EMAIL PROTECTED]] At 17:55 07-08-01, Stig Sæther Bakken wrote: Now we're talking! I assume it is not straightforward, what are the technical challenges in doing JIT module initialization? It's not much of a challenge really. If we decide it should be done, it can be done... Ok, so it's just a matter of minit_done and rinit_done properties for each module? Let's go for that, and either keep dl() or replace it with php_load_extension() (the difference being that the latter knows what file extension to use on your platform). sascha had a patch for this some time ago - the gain was near to zero. this might make sense once we hit the few hundred extension border... Right. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
At 09:39 AM 8/8/2001 +0200, Thies C. Arntzen wrote: On Wed, Aug 08, 2001 at 09:28:02AM +0200, Stig Sæther Bakken wrote: [Zeev Suraski [EMAIL PROTECTED]] At 17:55 07-08-01, Stig Sæther Bakken wrote: Now we're talking! I assume it is not straightforward, what are the technical challenges in doing JIT module initialization? It's not much of a challenge really. If we decide it should be done, it can be done... Ok, so it's just a matter of minit_done and rinit_done properties for each module? Let's go for that, and either keep dl() or replace it with php_load_extension() (the difference being that the latter knows what file extension to use on your platform). sascha had a patch for this some time ago - the gain was near to zero. this might make sense once we hit the few hundred extension border... Yeah I also remember it didn't give us anything. I think the most notably impact with shared libraries is the load time of the shared library itself. It is not significant in the web environment though when PHP is compiled as a server extension module. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
[Zeev Suraski [EMAIL PROTECTED]] At 19:40 06/08/2001, Andrei Zmievski wrote: On Mon, 06 Aug 2001, Zeev Suraski wrote: At 07:10 06/08/2001, Sterling Hughes wrote: What if you use 50 different shared extensions, for different scripts on the same box? Should you load them all in each time? I don't think so... Other than your phobia, there's no real reason not to do it :) No performance hit at all? Nothing measurable. That was actually measured (changing PHP to initialize extensions just-in-time, in case they're actually being used) - and it turned out it wasn't giving any noticeable performance gain. If there were a thousand extensions, we may have to rethink it - but the good solution would probably be JIT initialization. Now we're talking! I assume it is not straightforward, what are the technical challenges in doing JIT module initialization? - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
At 17:55 07-08-01, Stig Sæther Bakken wrote: Now we're talking! I assume it is not straightforward, what are the technical challenges in doing JIT module initialization? It's not much of a challenge really. If we decide it should be done, it can be done... Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
On Mon, 06 Aug 2001, Thies C. Arntzen wrote: thies Mon Aug 6 09:36:09 2001 EDT Modified files: /php4/ext/standardbasic_functions.c incomplete_class.c php_incomplete_class.h var.c /php4/ext/wddxwddx.c Log: we can no longer register internal-classes once the script is started. therefore the incomplete class is now registered at MINIT time. How it's not possible all of a sudden? -Andrei I think it would be a good idea. -- Mahatma Gandhi, when asked what he thought of Western civilization... -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
On Mon, Aug 06, 2001 at 09:08:05AM -0500, Andrei Zmievski wrote:
On Mon, 06 Aug 2001, Thies C. Arntzen wrote:
thies Mon Aug 6 09:36:09 2001 EDT
Modified files:
/php4/ext/standard basic_functions.c incomplete_class.c
php_incomplete_class.h var.c
/php4/ext/wddx wddx.c
Log:
we can no longer register internal-classes once the script is started.
therefore the incomplete class is now registered at MINIT time.
How it's not possible all of a sudden?
i don't think this is crucial for the gtk stuff as this
problem only arises once the request ends _and_ a new request
starts. the shutdown in the engine has been changed to only
destruct classes (from the end of the list) until the 1st
internal class is found. so:
?
class tubu {
}
dl(php-gtk);
class hallo {
}
?
would (now) destruct class hallo but not tubu. zeev assured me that
dl()'ing modules that created classes never really worked
(it would always have request shutdown-trouble as the
c-module would get unloaded but the class table would still
point into the unloiaded module). i kinda don't like it, but
i take zeevs word that it never worked properly.
tc
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
By the way, if it's really important, we can look into supporting it. The
way it was before - it worked in most cases (assuming you never tried to
use a class before you dl() the corresponding extension), but could result
in crashes in other cases.
I don't think it's very important, though. dl() should most probably be
deprecated from the language, as it's not supported in thread safe mode,
it's slow and insecure. It also creates a host of interesting bugs/buglets
that are difficult to hunt and fix. Other than that - it's great :)
Zeev
At 17:22 06/08/2001, Thies C. Arntzen wrote:
On Mon, Aug 06, 2001 at 09:08:05AM -0500, Andrei Zmievski wrote:
On Mon, 06 Aug 2001, Thies C. Arntzen wrote:
thies Mon Aug 6 09:36:09 2001 EDT
Modified files:
/php4/ext/standard basic_functions.c incomplete_class.c
php_incomplete_class.h var.c
/php4/ext/wddx wddx.c
Log:
we can no longer register internal-classes once the script is started.
therefore the incomplete class is now registered at MINIT time.
How it's not possible all of a sudden?
i don't think this is crucial for the gtk stuff as this
problem only arises once the request ends _and_ a new request
starts. the shutdown in the engine has been changed to only
destruct classes (from the end of the list) until the 1st
internal class is found. so:
?
class tubu {
}
dl(php-gtk);
class hallo {
}
?
would (now) destruct class hallo but not tubu. zeev assured me that
dl()'ing modules that created classes never really worked
(it would always have request shutdown-trouble as the
c-module would get unloaded but the class table would still
point into the unloiaded module). i kinda don't like it, but
i take zeevs word that it never worked properly.
tc
--
Zeev Suraski [EMAIL PROTECTED]
CTO co-founder, Zend Technologies Ltd. http://www.zend.com/
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
On Mon, 06 Aug 2001, Thies C. Arntzen wrote:
i don't think this is crucial for the gtk stuff as this
problem only arises once the request ends _and_ a new request
starts. the shutdown in the engine has been changed to only
destruct classes (from the end of the list) until the 1st
internal class is found. so:
?
class tubu {
}
dl(php-gtk);
class hallo {
}
?
would (now) destruct class hallo but not tubu. zeev assured me that
dl()'ing modules that created classes never really worked
(it would always have request shutdown-trouble as the
c-module would get unloaded but the class table would still
point into the unloiaded module). i kinda don't like it, but
i take zeevs word that it never worked properly.
I haven't run into problems with it yet, but I'll keep this in mind, I
guess.
-Andrei
* http://www.zend.com/comm_person.php?id=24 *
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
On Mon, 06 Aug 2001, Zeev Suraski wrote: By the way, if it's really important, we can look into supporting it. The way it was before - it worked in most cases (assuming you never tried to use a class before you dl() the corresponding extension), but could result in crashes in other cases. I don't think it's very important, though. dl() should most probably be deprecated from the language, as it's not supported in thread safe mode, it's slow and insecure. It also creates a host of interesting bugs/buglets that are difficult to hunt and fix. Other than that - it's great :) Deprecate dl()? I think it's one of the most useful functions... :) -Andrei * Syntactic sugar causes cancer of the semicolon. -- Alan Perlis * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
[Zeev Suraski [EMAIL PROTECTED]] By the way, if it's really important, we can look into supporting it. The way it was before - it worked in most cases (assuming you never tried to use a class before you dl() the corresponding extension), but could result in crashes in other cases. I don't think it's very important, though. dl() should most probably be deprecated from the language, as it's not supported in thread safe mode, it's slow and insecure. It also creates a host of interesting bugs/buglets that are difficult to hunt and fix. Other than that - it's great :) Uhm, are you suggesting we take away the possibility of loading extensions at run-time? - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
At 17:42 06/08/2001, Andrei Zmievski wrote: On Mon, 06 Aug 2001, Zeev Suraski wrote: By the way, if it's really important, we can look into supporting it. The way it was before - it worked in most cases (assuming you never tried to use a class before you dl() the corresponding extension), but could result in crashes in other cases. I don't think it's very important, though. dl() should most probably be deprecated from the language, as it's not supported in thread safe mode, it's slow and insecure. It also creates a host of interesting bugs/buglets that are difficult to hunt and fix. Other than that - it's great :) Deprecate dl()? I think it's one of the most useful functions... :) How so? I can understand that people get used to it, but it's really bad. extensions should be loaded in the php.ini file. There's really no good reason for using dl() over the php.ini method. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
At 17:49 06/08/2001, Stig Sæther Bakken wrote: [Zeev Suraski [EMAIL PROTECTED]] By the way, if it's really important, we can look into supporting it. The way it was before - it worked in most cases (assuming you never tried to use a class before you dl() the corresponding extension), but could result in crashes in other cases. I don't think it's very important, though. dl() should most probably be deprecated from the language, as it's not supported in thread safe mode, it's slow and insecure. It also creates a host of interesting bugs/buglets that are difficult to hunt and fix. Other than that - it's great :) Uhm, are you suggesting we take away the possibility of loading extensions at run-time? Depending on which run-time you mean, yes. I don't think it should be possible to load extensions from within a PHP script. Note that dl() never really behaved properly. It was always broken to one degree or another. Also, it'll be completely unavailable in the thread safe version of PHP, so we might as well deprecate it completely. Loading extensions in the php.ini file is still very much possible. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
On Mon, 06 Aug 2001, Zeev Suraski wrote: How so? I can understand that people get used to it, but it's really bad. extensions should be loaded in the php.ini file. There's really no good reason for using dl() over the php.ini method. Of course there is. One example is using the same PHP binary to run scripts that use different extensions that wouldn't necessarily want to load all the time through php.ini. -Andrei When we eliminate the impossible, whatever remains, however improbable, must be true. -- Sherlock Holmes -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
I disagree, is there any way dl() can be fixed, because it is a useful function... On Mon, 06 Aug 2001, Zeev Suraski wrote: At 17:49 06/08/2001, Stig Sæther Bakken wrote: [Zeev Suraski [EMAIL PROTECTED]] By the way, if it's really important, we can look into supporting it. The way it was before - it worked in most cases (assuming you never tried to use a class before you dl() the corresponding extension), but could result in crashes in other cases. I don't think it's very important, though. dl() should most probably be deprecated from the language, as it's not supported in thread safe mode, it's slow and insecure. It also creates a host of interesting bugs/buglets that are difficult to hunt and fix. Other than that - it's great :) Uhm, are you suggesting we take away the possibility of loading extensions at run-time? Depending on which run-time you mean, yes. I don't think it should be possible to load extensions from within a PHP script. Note that dl() never really behaved properly. It was always broken to one degree or another. Also, it'll be completely unavailable in the thread safe version of PHP, so we might as well deprecate it completely. Loading extensions in the php.ini file is still very much possible. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
At 17:52 06/08/2001, Andrei Zmievski wrote: On Mon, 06 Aug 2001, Zeev Suraski wrote: How so? I can understand that people get used to it, but it's really bad. extensions should be loaded in the php.ini file. There's really no good reason for using dl() over the php.ini method. Of course there is. One example is using the same PHP binary to run scripts that use different extensions that wouldn't necessarily want to load all the time through php.ini. That's one of the places where the PHP/Web functionality and a PHP-standalone functionality collide. In a Web environment, it really makes no sense. The right solution for that is most probably going to be adding a command line option that loads an extension (we already have that for Zend extensions). Loading extensions from within a script is simply a pain to support, and it doesn't really give you anything. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
Please don't just say it's useful, please say why :) dl() has absolutely nothing over loading in php.ini, and has many drawbacks. Zeev At 17:55 06/08/2001, Andy wrote: I disagree, is there any way dl() can be fixed, because it is a useful function... On Mon, 06 Aug 2001, Zeev Suraski wrote: At 17:49 06/08/2001, Stig Sæther Bakken wrote: [Zeev Suraski [EMAIL PROTECTED]] By the way, if it's really important, we can look into supporting it. The way it was before - it worked in most cases (assuming you never tried to use a class before you dl() the corresponding extension), but could result in crashes in other cases. I don't think it's very important, though. dl() should most probably be deprecated from the language, as it's not supported in thread safe mode, it's slow and insecure. It also creates a host of interesting bugs/buglets that are difficult to hunt and fix. Other than that - it's great :) Uhm, are you suggesting we take away the possibility of loading extensions at run-time? Depending on which run-time you mean, yes. I don't think it should be possible to load extensions from within a PHP script. Note that dl() never really behaved properly. It was always broken to one degree or another. Also, it'll be completely unavailable in the thread safe version of PHP, so we might as well deprecate it completely. Loading extensions in the php.ini file is still very much possible. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
BTW, there's no good reason not to load all of the extensions you may need in all of your scripts from php.ini. Loading many extensions doesn't pose a significant/noticeable load. Loading using dl() does. Zeev At 17:52 06/08/2001, Andrei Zmievski wrote: On Mon, 06 Aug 2001, Zeev Suraski wrote: How so? I can understand that people get used to it, but it's really bad. extensions should be loaded in the php.ini file. There's really no good reason for using dl() over the php.ini method. Of course there is. One example is using the same PHP binary to run scripts that use different extensions that wouldn't necessarily want to load all the time through php.ini. -Andrei When we eliminate the impossible, whatever remains, however improbable, must be true. -- Sherlock Holmes -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
On Mon, 06 Aug 2001, Zeev Suraski wrote: BTW, there's no good reason not to load all of the extensions you may need in all of your scripts from php.ini. Loading many extensions doesn't pose a significant/noticeable load. Loading using dl() does. Can you explain why the difference matters? -Andrei The church is near but the road is icy; the bar is far away but I will walk carefully. -- Russian proverb -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
[Zeev Suraski [EMAIL PROTECTED]] Please don't just say it's useful, please say why :) dl() has absolutely nothing over loading in php.ini, and has many drawbacks. Please allow me to coin a new term: Zeev-ism. Zeev-isms are of the form users don't need X or 95.6% of the scripts out there don't need Y. ;-) The fact is that a lot of people (typically ISP users) don't have access to php.ini or .htaccess. If these people need a third party extension, or one that was not built in their ISP's version of PHP, they either have to get their ISP to include it (and if the ISP is big enough and the client small enough, they won't care), or use dl(). If their ISP hasn't disabled that function, in which case they're screwed anyway of course. I do get kinda worried when you pop out a statement like we're probably going to deprecate dl() anyway, being able to load extensions at run-time sort of is one of PEAR's foundations. Let's try to fix these problems rather than cripping PHP. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
At 18:07 06/08/2001, Andrei Zmievski wrote: On Mon, 06 Aug 2001, Zeev Suraski wrote: BTW, there's no good reason not to load all of the extensions you may need in all of your scripts from php.ini. Loading many extensions doesn't pose a significant/noticeable load. Loading using dl() does. Can you explain why the difference matters? Sure. dl() means that module_init is done multiple times. It also means that module_shutdown is done multiple times, *and* has to take care of cleaning up after the extension *completely*. That is, clean whatever functions, classes, ini entries and callbacks this function may have registered. Right now, only PHP functions and ini entries (to a degree) are handled properly. Drawbacks: - It's slow. We encourage putting expensive operations into the module_init, using dl() means they end up being done multiple times. - Under Apache, it's even worse - since in addition to slowliness, it also ends up consuming significantly more memory, since any memory the extension allocates in module_init (e.g., the function entries it registers) cannot be shared between the processes. - It prevents the engine from optimizing function calls at compile time, by looking at what kind of arguments these functions expect. This is left for run-time, which results in significantly slower run-time performance. - Literally, none of the extensions properly cleans up after itself, leaving PHP in various degrees of instability. This rarely translates to crashes, because people don't usually have a script in which they dl() and then use a class, another script in which they use the class without dl()'ing first, and call the 2nd script right after calling the 1st one. Still, from a cleanliness perspective and in theory, it's bad. - Another buglet resulting from this is the crash in debug mode, in case of a memory leak inside an extension, which is reported in the bugs db. It's no biggy, but also has no good solution. I don't think the solution should be fixing all of the extensions to clean up after themselves, when the only gain is having dl() work, and when using dl() is almost always(*) significantly worse than simply adding the extension to the php.ini file. (*) I can't think of any case in which it isn't, but I'm staying humble :) Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
See my letter to Andrei. I've yet to see an ISP that (knowingly) allows users to load extensions, and wouldn't agree to add them to the php.ini file. This isn't a case of me saying users don't need X or 95.6% of the scripts out there don't need Y. This is me saying that dl() is *bad*, even if people got used to using it, which is why it should be deprecated. Again, notice that it has been deprecated for a long while in thread-safe mode, which means people who develop under Windows (a huge share) don't have it for over a year. dl() is bad in pretty much every sense, including the new sense you mentioned in your letter - dl()'ing extensions in a shared environment. Forcing the ISP to admit any extensions into the php.ini file before it gets loaded to the server is a good thing. If dl() is one of PEAR's foundations, it's time to dig it up and replace it with something more sound and stable :) Using php.ini for loading extensions should be the way to go. Zeev At 18:18 06/08/2001, Stig Sæther Bakken wrote: [Zeev Suraski [EMAIL PROTECTED]] Please don't just say it's useful, please say why :) dl() has absolutely nothing over loading in php.ini, and has many drawbacks. Please allow me to coin a new term: Zeev-ism. Zeev-isms are of the form users don't need X or 95.6% of the scripts out there don't need Y. ;-) The fact is that a lot of people (typically ISP users) don't have access to php.ini or .htaccess. If these people need a third party extension, or one that was not built in their ISP's version of PHP, they either have to get their ISP to include it (and if the ISP is big enough and the client small enough, they won't care), or use dl(). If their ISP hasn't disabled that function, in which case they're screwed anyway of course. I do get kinda worried when you pop out a statement like we're probably going to deprecate dl() anyway, being able to load extensions at run-time sort of is one of PEAR's foundations. Let's try to fix these problems rather than cripping PHP. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
On Mon, 06 Aug 2001, Zeev Suraski wrote: Drawbacks: - It's slow. We encourage putting expensive operations into the module_init, using dl() means they end up being done multiple times. - Under Apache, it's even worse - since in addition to slowliness, it also ends up consuming significantly more memory, since any memory the extension allocates in module_init (e.g., the function entries it registers) cannot be shared between the processes. This doesn't apply under the standalone version, which is what I'm mainly worried about. - It prevents the engine from optimizing function calls at compile time, by looking at what kind of arguments these functions expect. This is left for run-time, which results in significantly slower run-time performance. Can you quantify significantly? - Literally, none of the extensions properly cleans up after itself, leaving PHP in various degrees of instability. This rarely translates to crashes, because people don't usually have a script in which they dl() and then use a class, another script in which they use the class without dl()'ing first, and call the 2nd script right after calling the 1st one. Still, from a cleanliness perspective and in theory, it's bad. I see. I wasn't aware that the extension was supposed to clean up the classes it registers. I will fix PHP-GTK behavior on this. -Andrei Linux is like living in a teepee. No Windows, no Gates, Apache in house. - Usenet signature -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
On Mon, Aug 06, 2001 at 10:34:34AM -0500, Andrei Zmievski wrote: On Mon, 06 Aug 2001, Zeev Suraski wrote: Drawbacks: - It's slow. We encourage putting expensive operations into the module_init, using dl() means they end up being done multiple times. - Under Apache, it's even worse - since in addition to slowliness, it also ends up consuming significantly more memory, since any memory the extension allocates in module_init (e.g., the function entries it registers) cannot be shared between the processes. This doesn't apply under the standalone version, which is what I'm mainly worried about. - It prevents the engine from optimizing function calls at compile time, by looking at what kind of arguments these functions expect. This is left for run-time, which results in significantly slower run-time performance. Can you quantify significantly? - Literally, none of the extensions properly cleans up after itself, leaving PHP in various degrees of instability. This rarely translates to crashes, because people don't usually have a script in which they dl() and then use a class, another script in which they use the class without dl()'ing first, and call the 2nd script right after calling the 1st one. Still, from a cleanliness perspective and in theory, it's bad. I see. I wasn't aware that the extension was supposed to clean up the classes it registers. I will fix PHP-GTK behavior on this. don't think there's an API for that. we would have to add the MODULE_NUMBER to the class-entry and then (when unloading the module) also destroy the classes that that module defined. i think constants and functions already do this. tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
On Mon, 06 Aug 2001, Thies C. Arntzen wrote: don't think there's an API for that. we would have to add the MODULE_NUMBER to the class-entry and then (when unloading the module) also destroy the classes that that module defined. i think constants and functions already do this. Hmm, right, they don't have module_number.. -Andrei * Why is it always Segmentation's fault? * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
At 06:30 06/08/2001, Sterling Hughes wrote: On Mon, 6 Aug 2001, Andrei Zmievski wrote: On Mon, 06 Aug 2001, Zeev Suraski wrote: How so? I can understand that people get used to it, but it's really bad. extensions should be loaded in the php.ini file. There's really no good reason for using dl() over the php.ini method. Of course there is. One example is using the same PHP binary to run scripts that use different extensions that wouldn't necessarily want to load all the time through php.ini. Also, just to mention, right now it might not be that big a deal to load them all in php.ini (well something as big PHP-GTK would be, but...), however, as PHP gets more and more extensions written in C, there needs to be this functionality. Why? Whatever extension you use on your box, put them in the php.ini. dl() is never a better option. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
By the way, I can't really quantify significantly, as it depends on what kind of minit you have. For a module such as the COM module, it can double the amount of time it takes the script to run (if you load typelibs). For some other modules, it can be almost anything, if your minit is mostly empty. As a general rule, it's a bad thing, since it repeats things which don't have to be repeated. At 18:34 06/08/2001, Andrei Zmievski wrote: On Mon, 06 Aug 2001, Zeev Suraski wrote: Drawbacks: - It's slow. We encourage putting expensive operations into the module_init, using dl() means they end up being done multiple times. - Under Apache, it's even worse - since in addition to slowliness, it also ends up consuming significantly more memory, since any memory the extension allocates in module_init (e.g., the function entries it registers) cannot be shared between the processes. This doesn't apply under the standalone version, which is what I'm mainly worried about. - It prevents the engine from optimizing function calls at compile time, by looking at what kind of arguments these functions expect. This is left for run-time, which results in significantly slower run-time performance. Can you quantify significantly? - Literally, none of the extensions properly cleans up after itself, leaving PHP in various degrees of instability. This rarely translates to crashes, because people don't usually have a script in which they dl() and then use a class, another script in which they use the class without dl()'ing first, and call the 2nd script right after calling the 1st one. Still, from a cleanliness perspective and in theory, it's bad. I see. I wasn't aware that the extension was supposed to clean up the classes it registers. I will fix PHP-GTK behavior on this. -Andrei Linux is like living in a teepee. No Windows, no Gates, Apache in house. - Usenet signature -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
On Mon, 06 Aug 2001, Zeev Suraski wrote: By the way, I can't really quantify significantly, as it depends on what kind of minit you have. For a module such as the COM module, it can double the amount of time it takes the script to run (if you load typelibs). For some other modules, it can be almost anything, if your minit is mostly empty. As a general rule, it's a bad thing, since it repeats things which don't have to be repeated. I thought you meant significantly worse run-time perfomance because the engine can't optimize for function arguments, not because of what kind of MINIT an extension has. We're still talking about standalone PHP binary here. -Andrei A room without books is like a body without a soul. -- Marcus Tullius Cicero (106-43 B.C.) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
At 19:29 06/08/2001, Andrei Zmievski wrote: On Mon, 06 Aug 2001, Zeev Suraski wrote: By the way, I can't really quantify significantly, as it depends on what kind of minit you have. For a module such as the COM module, it can double the amount of time it takes the script to run (if you load typelibs). For some other modules, it can be almost anything, if your minit is mostly empty. As a general rule, it's a bad thing, since it repeats things which don't have to be repeated. I thought you meant significantly worse run-time perfomance because the engine can't optimize for function arguments, not because of what kind of MINIT an extension has. We're still talking about standalone PHP binary here. Ah. Well, YMMV. If you have repeated calls to functions (not class methods, these are not optimized), it can be quite significant - you have an extra opcode that includes some stack manipulation, string duplication and strtolower of the function name, and slower pass_param opcodes. I never actually benchmarked it, but it can be quite significant. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
At 07:10 06/08/2001, Sterling Hughes wrote: What if you use 50 different shared extensions, for different scripts on the same box? Should you load them all in each time? I don't think so... Other than your phobia, there's no real reason not to do it :) Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
On Mon, 06 Aug 2001, Zeev Suraski wrote: At 07:10 06/08/2001, Sterling Hughes wrote: What if you use 50 different shared extensions, for different scripts on the same box? Should you load them all in each time? I don't think so... Other than your phobia, there's no real reason not to do it :) No performance hit at all? -Andrei * Life may be expensive, but it includes an annual free trip around the sun. * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
At 19:40 06/08/2001, Andrei Zmievski wrote: On Mon, 06 Aug 2001, Zeev Suraski wrote: At 07:10 06/08/2001, Sterling Hughes wrote: What if you use 50 different shared extensions, for different scripts on the same box? Should you load them all in each time? I don't think so... Other than your phobia, there's no real reason not to do it :) No performance hit at all? Nothing measurable. That was actually measured (changing PHP to initialize extensions just-in-time, in case they're actually being used) - and it turned out it wasn't giving any noticeable performance gain. If there were a thousand extensions, we may have to rethink it - but the good solution would probably be JIT initialization. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
On Mon, 06 Aug 2001, Zeev Suraski wrote: Nothing measurable. That was actually measured (changing PHP to initialize extensions just-in-time, in case they're actually being used) - and it turned out it wasn't giving any noticeable performance gain. If there were a thousand extensions, we may have to rethink it - but the good solution would probably be JIT initialization. I have no problems with JIT-Init. We even have a marketable name for it, then. :) -Andrei * Marriage is not a word. It's a sentence. Life-long sentence. * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
At 19:45 06/08/2001, Andrei Zmievski wrote: On Mon, 06 Aug 2001, Zeev Suraski wrote: Nothing measurable. That was actually measured (changing PHP to initialize extensions just-in-time, in case they're actually being used) - and it turned out it wasn't giving any noticeable performance gain. If there were a thousand extensions, we may have to rethink it - but the good solution would probably be JIT initialization. I have no problems with JIT-Init. We even have a marketable name for it, then. :) :) Anyway, I'm off for a few hours now, reinstalling my machine. I'll answer anything that comes up when I get back ;) Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
On Mon, 06 Aug 2001, Zeev Suraski wrote: I think the disk weights about the same regardless of the data inside it :) Yes, but 50 extensions will consume more memory than 1. -Andrei In My Egotistical Opinion, most people's C programs should be indented six feet downward and covered with dirt. -- Blair P. Houghton -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
Hi, Deprecate dl()? I think it's one of the most useful functions... :) How so? I can understand that people get used to it, but it's really bad. extensions should be loaded in the php.ini file. There's really no good reason for using dl() over the php.ini method. I agree with you when we are talking about using PHP in a webserver. However, I am seeing more and more use of PHP as a generic scripting language. In this situation, I think dl() is very useful... Imagine a application written in PHP that has a 'special' extension. For example, an extension to access a scanner. You don't want this loaded everywhere, just in your scanner application, and certainly not in your webserver. In a few words: For a webserver: ban dl() For generic scripting: keep dl() Sander. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
In a few words: For a webserver: ban dl() For generic scripting: keep dl() What's really the point of protecting people from their stupidity. If you're going to keep it in the generic scripting engine (which I think has lots of value), why not keep it in the webserver engine as well. There are plenty of php extensions which, imho, operate way to slow to called on a busy production site. Does that mean they should be eliminated? No, it means they should just be used with a 'buyer-beware' mentality. George -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
At 23:57 06-08-01, Sander Steffann wrote: Hi, Deprecate dl()? I think it's one of the most useful functions... :) How so? I can understand that people get used to it, but it's really bad. extensions should be loaded in the php.ini file. There's really no good reason for using dl() over the php.ini method. I agree with you when we are talking about using PHP in a webserver. However, I am seeing more and more use of PHP as a generic scripting language. In this situation, I think dl() is very useful... Imagine a application written in PHP that has a 'special' extension. For example, an extension to access a scanner. You don't want this loaded everywhere, just in your scanner application, and certainly not in your webserver. You can achieve the same goal using a command line entry. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
I disagree in two levels. First, I think that saying We can't protect people from their stupidity, so let's lift all bars is just plain wrong and a bad approach in a real world situation. Sure, it's true, but we can definitely reduce the risks involved in common mistakes that people make. Not bulletproof, but sometimes simply hinting people not to go around places where shots are fired is good enough. On the second level, there are several other reasons not to keep dl() which aren't related to security or preventing people from doing the wrong things. These are: - Slow performance, encourages slow app writing - Complicates the development of extensions and the engine - Will not work in thread safe mode All in all, dl() is simply bad, in just about every level. Zeev At 00:03 07-08-01, George Schlossnagle wrote: In a few words: For a webserver: ban dl() For generic scripting: keep dl() What's really the point of protecting people from their stupidity. If you're going to keep it in the generic scripting engine (which I think has lots of value), why not keep it in the webserver engine as well. There are plenty of php extensions which, imho, operate way to slow to called on a busy production site. Does that mean they should be eliminated? No, it means they should just be used with a 'buyer-beware' mentality. George -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
