2011/10/26 Matthew Weier O'Phinney <weierophin...@php.net>: > > My main point, however, is that the standard was ratified quite some > time ago already -- we just now have parties interested in creating a > C-level implementation compatible with the standard to (a) make usage > simpler, and (b) better optimize performance. We should not be debating > the standard here, just the implementation. >
I'd like to object there. Now that we are discussing it on an open mailing list again, both seem actually quite relevant. This is not the most important aspect here, but is there a *practical* need to have a C implementation of this autoloader scheme? I mean no disrespect to the author; the code looks very nice and all. But it hasn't exactly been widely tested yet. Moreover there are already many psr-0 userland implementations; practically all with functional additions. Besides that SCL might not displace everyone of them, it also seems kind of unnecessary. Because those existing autoloaders in userland are fully operational.? Having a default-proclaimed scheme in PHP core also feels a bit contrary to allowing more specific userland autloaders. (Though still indespensable for absorbing local customization and deployment discrepancies.) I get that this is secondarily intended as optimization. But how much would this matter in practice? It's mostly the bloaty frameworks (if I may say so) that were to consider using it; where the benefit might be less measurable. (And no, the smaller and newer frameworks don't all follow psr-0.) > >>> The url for the RFC is: https://wiki.php.net/rfc/splclassloader But let's also discuss the *unmentioned* side effect of that proposal. (I realize I'm opening a can of worms and a meta discussion here. But I'd __politely request that people get over it already. And no, I believe reducing case ambiguity was sensible language design.) Now, PHP has case-insensitive identifiers. This includes function names, class names, and not least namespaces. The proposed SplClassLoader would break that. Like PSR-0 it cannot satisfy class name requests case-insensitively. The implementation approach is indeterminate, depending on filesystem. Now the desire to enforce coding styles per autoloader will certainly come up as post-factum rationalization here. But I'd also like to assert() that this creeping-in is even less acceptable from a language design point of view. For PHP6 there were discussions to drop BC and make identifiers case- sensitive, just like in most other C-style languages. This has been shot down. So the question becomes: should such a behavioural change be introduced through the backdoor, in a PHP 5.x relase, by an autoloader? Or is that issue too minor to care? After all it would be just a second implementation, besides spl_autoload(). And again, retirement of custom autoloaders is unlikely either way. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
