Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:25754 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 81976 invoked by uid 1010); 18 Sep 2006 09:55:44 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 81957 invoked from network); 18 Sep 2006 09:55:44 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 18 Sep 2006 09:55:44 -0000 Authentication-Results: pb1.pair.com smtp.mail=zeev@zend.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=zeev@zend.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain zend.com designates 80.74.107.235 as permitted sender) X-PHP-List-Original-Sender: zeev@zend.com X-Host-Fingerprint: 80.74.107.235 mail.zend.com Linux 2.5 (sometimes 2.4) (4) Received: from [80.74.107.235] ([80.74.107.235:24311] helo=mail.zend.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 09/94-50914-E1D6E054 for ; Mon, 18 Sep 2006 05:55:44 -0400 Received: (qmail 6294 invoked from network); 18 Sep 2006 09:54:23 -0000 Received: from localhost (HELO zeev-notebook.zend.com) (127.0.0.1) by localhost with SMTP; 18 Sep 2006 09:54:23 -0000 Message-ID: <7.0.1.0.2.20060918124644.0ab89798@zend.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 18 Sep 2006 12:55:26 +0300 To: LAUPRETRE =?iso-8859-1?Q?Fran=E7ois?= (P) Cc: , In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [PHP-DEV] Re: What's wrong with dl? From: zeev@zend.com (Zeev Suraski) At 12:39 18/09/2006, 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, There are good reasons to remove it. It's not that we suddenly thought PHP would be a better language without dl(), it just doesn't fit the Web model PHP is used with and cannot be implemented reliably. That's why we kept it where it makes sense (CLI), and deprecated it in the web SAPIs. By the way, a smart autoloader in a real world PHP environment will most certainly always be *less* efficient than loading the extension at startup, because it cannot be shared between instances. Zeev