Re: my take on PHP 6, part 2

On Mon, 2014-02-17 at 15:02 -0600, Ralph Schindler wrote: > I think the idea here is to be able to have per-project extension > dependencies, as you said, with composer. This would be ideal in a way > for the ecosystem to vet extensions before inclusion in core. But > currently, unless you own the system, extensions are extremely > inaccessible to gain any real momentum. Right, but this isn't a trivial problem. We must ensure that - extensions load quickly (right now we can have relatively expensive MINIT code) - extensions survive loading at run time (some extensions, like session, eventually send HTTP headers, many won't handle "class/function already defined" errors well) - we don't run into issues in threaded environments (as long as we support those) - we can properly unload and clean up (some extensions mess with internal data structures, sometimes the OS has issue with releasing all symbols etc.) - we don't open too much of a pandorra's box in regards to security (if we restrict it to extension_dir it is useless for the composer case, if not we provide a tool to bypass all of PHP's blocking mechanisms) - ... I think it is great to do, but a proper solution is not a small project but might require a revamp of many APIs. And I want to remind about my typical opinion: We should try to require as little extensions as possible and do as many things as possible (in a usable way) in userland. If we spend time on making PHP faster we reduce the need for extensions even more. johannes