# What's wrong with dl?

- Thread: https://externals.io/message/25752
- Original archive: https://news-web.php.net/php.internals/25752
- Started by francois.laupretre@ratp.fr on 2006-09-18T09:39:56+00:00
- Messages: 2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #25752 — francois.laupretre@ratp.fr — 2006-09-18T09:39:56+00:00

URL: https://externals.io/message/25752#25752

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:
> > […]
> 
> `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

---

## #25754 — Zeev Suraski — 2006-09-18T09:55:26+00:00

URL: https://externals.io/message/25752#25754 · In reply to: #25752

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