OK. Thanks for your answers, I didn't see this problem with each thread restarting in an 'empty' state and having to reload extensions through the autoloader. Even if loaded extensions could be registered in shared memory, I agree: it is much better to remove dl() except in CLI mode.
Maybe the documentation should be updated to state that dl() is not deprecated in the CLI SAPI. More generally, but you certainly already thought about it. Is there a place to keep a track of this kind of decision, and their justification ? Typically, I wouldn't have asked this question if I had found a place where it was explained why, when, and how the decision to remove dl() was taken. And Michael would have asked his question because this place would contain a comment saying that dl() will be maintained for CLI. What I think about is a kind of RFC process, which would provide features and benefits we cannot have with a mailing list : - The most important one is to 'keep tracks'. The mailing list is a flow of messages. They come and go, and the memory is provided by its users: everyday, you and others waste some time replying things like 'We decided that...' or 'We already talked about this...' to people who lack a proper source of information. - the 'feature request' section in the bug database is not the proper tool to do it. There are too many items in it. There is no way to vote for or against a proposal. And it is not the place for a real 'RFC' document. - Some months ago, somebody (I think it was you ?) proposed to stop modifying the PHP syntax for a while. And in the follow-ups, someone wrote that nobody likes to write documentation and, if we forced people to formally write a proposal to go through a structured process of approval, it would refrain people to propose ideas and it would finally be a bad idea. I think exactly the opposite. By proposing ideas in a mailing list, even if you have written a real RFC document for your idea, it will be very hard to have people read it. Just because it is lost in the flow, and people won't take time to really think about it. And even if you have been studying the subject for several months, nothing will distinguish your message from the rest of the flow. If we had a structured RFC process, it would allow people to write a real document with every aspects of their idea. It also would make a selection as I tend to think that, if you are not ready to explain it on a structured 2-3 page form, your idea is, either not so good, or not mature enough to request some time from your peers. - Unfortunately, when looking at the mailing list, everybody chooses the messages it will read based on the subject and the author. But, it has a negative side effect, which is that it is hard for 'unknown authors' (everybody except 10 or 15 people on PHP/Internals) to have their proposals considered seriously. And, for a project like PHP today, IMHO, it is very important not to ignore any good idea coming from anywhere (and it is not to say my own ideas are good :). - The best alternate way is certainly to go to the PHP conferences and meet people. I'd love to but I don't have enough time nor money for that. And it would be too bad to have to meet people in person on a subject like PHP :) What do you think about it ? If you are interested, I am ready to work on this subject. Francois -----Original Message----- From: Zeev Suraski [mailto:[EMAIL PROTECTED] Sent: Monday, September 18, 2006 11:55 AM To: LAUPRETRE François (P) Cc: [EMAIL PROTECTED]; internals@lists.php.net Subject: Re: [PHP-DEV] Re: What's wrong with dl? 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
