Re: Re: What's wrong with dl?

It is impossible to implement it reliably in any of the threaded sapis, so by definition it can only possibly work in a limited set of them which is why you shouldn't ever use it for any sort of portable code. CLI by definition is not threaded, so that is one case where it could stay. -Rasmus LAUPRETRE François (P) wrote:

I never saw any argument justifying the removal of the dl() feature, even if the CLI SAPI keeps it. But I can give at least two against it : - If extensions cannot be loaded from the PHP code any more, it becomes impossible to autoload them when needed. As I wrote in another message, one of the benefits a 'smart' autoload handler could bring, would be to allow extension autoloading. And not only for CLI programs: when you distribute a software, it would be much better to autoload extensions in a transparent manner than require an unexperienced user to modify his php.ini file. - Unless there's a good reason to suppress this feature, I don't see why we should introduce a difference between the CLI SAPI and other interfaces. IMHO, the decision to remove dl() is wrong. Maybe it looked like a good idea at first, but considering all its implications, it is not. Francois Edin Kadribasic wrote:

Michael B Allen wrote:

Our CLI module installer uses dl() to manually load the module and validate some basic functionality. This is a very nice feature and I'm disappointed to see it has been deprecated. Will there be any equivalent functionality moving forward? The extension directive is clumsey in this scenario because it would require running a separate script.

dl() is scheduled to be removed from all other SAPI's. I believe that there are no current plans to deprecate it from the CLI version of PHP. Edin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php