> I thought we weren't wasting any more time with this? :) Yeah, I'm getting realy tired of having to argue for something that should be a base part of the language. So let me explain this an entirely different way.
Lets forget about dl() altogether for just a second so we can focus instead on the issue I am trying to get through to you. What module/extension developers need is a way to effectively write extensions that are mixed PHP/C/C++. The PHP part needs some way to say 'hey php engine, you have to load xxx.dll now'. This should NOT be reliant on php.ini. If a module/extension is placed into an include/extension path directory (defined in the php.ini), it should be considered fair game to be loaded at ANY time by php. C code loaded at any given point should remain loaded until the process exits (this deals with performance issues). Having this feature solves several issues for everyone: 1. no reliance on a single configuration on a system where multiple configurations are desirable 2. ease of use and installation for php users 3. ease of distribution for developers 4. you no longer have to have multiple php.ini files for different configurations. > In all of what you said, I haven't heard any explanation to why you've > grown to hate php.ini, and frankly, I think that php.ini is more than > sufficient. I think I've been fairly fair to php.ini in saying there are definitly things it should be used for, and 'preloading' extensions is handled there quite nicely, but we still need a runtime method. My dislike for it is that it makes having multiple configurations more difficult. I think a basic difference of opinion here is that you feel php.ini is fine, I find it limiting and anoying for multiple configuration systems. > If you're talking about adding a function that will essentially do what > extension= does in php.ini, only at runtime (i.e., load the module > process-wide, and have it stay there), then you're still violating a basic > rule in PHP (pages will behave differently according to whether or not a > page with the loading statement has been accessed). That's such a non issue. You get an error just like you do now if a module is not loaded and you try to use it. Anyway, a year ago I probably would agree with you about this, but having had other scripting langugages thrust into my life, I've learned to realy appreciate some of the basic things about them, one being that I do not have to go and change a central configuration of the language itself evertime I want to load a different extension. > With Stas's idea of an auto-load directory, even the > complaints of the text-editor-challenged users will be answered. I actually realy dislike that idea. It's no different than having to put something in php.ini. All the dll's get loaded for any instance of PHP unless you have seperate autoload directories for seperate configurations. It just gets more and more into hairy config situations, which is what I am trying to avoid. > In a retaliatory preemptive attempt to end this thread, I also took the > liberty to snip away the rest of your post and end it here, except for one > comment: > > >First, Perl is used twice as much as PHP under Apache on top web sites (*). > > I'll take the liberty to consider this statement quite baseless, given the > information I've seen. Taking away the context in which it was responding to does indeed make it quite baseless, because it's not about how much Perl is used anywhere. I made the point that Perl and Python both allow for dynamicly loaded modules, you said they are not designed for web server use, especially in multithreaded situations, and I replied with the fact that Perl is used twice as much on top sites, and Python is much better at threading that either Perl or PHP. Context in conversasion is quite important. Shane -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
