Hi!
Sure, but this is another great example. If you wrote an RFC that basically said, "Let's rewrite the engine" I bet it would get a lot of
We already have such proposal. It's called unicode support. Everybody talks about how great it would be to have one. If we had a vote, I bet there would be zero votes against in from the community. But we all know by now it's not that easy and if there was a patch to do it this patch would with 99% probability fail. Even if it were perfect, it would take very long time to ensure that, and very deep and passionate discussion. That's because this thing is much harder and more complex than it appears on the first sight, until you really start to think about all the consequences. Having such matters decided on simple vote is madness.
That's another myth spread by the opponents of making our process open. All RFCs proposed has been proposed with patches, implemented by the proposers, with or without the help of other core developers.
The problem is not having patches, the problem is having the patches that won't cause trouble in other parts of PHP. For example - and please understand I'm not trying to single out anybody, it's just and example - IIRC for spl loader patch right now there's a problem of it trying to load non-existing files if non-existing class is checked. We'd have to deal with this problem. It also has something called "include path" which works totally different from PHP's include path. We'd have to deal with that too, and with users asking us why we call two different things "include path" and then ranting all over the internet how PHP is an inconsistent mess. Also I see that get_filename() modifies its arguments, while getPath() passes its argument directly to it. Not sure it's the best idea. Also, not sure if it's an issue or not, but it looks like the included files will be run in the scope of whichever code initiated the autoloader. Which is not the case with PHP-based loaders. I know everybody writes good code which would never spill anything to including scope but... :)
-- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
