Hello, > Already answered before. Performance is important. A native C > > implementation is much faster than a PHP code implementation. > > Well, that's always a safe assumption. But a shiny benchmark would be > useful in this review. > Interesting hard fact would to be know if -for the overall framework speed- > it makes a significant difference with or without bytecode cache. Shaving > off a few milliseconds, always cool. But percentages, more fascinating. >
This is mostly relevant for performance in non-bytecode caches. Just as most autoloading that leverages include paths. Same problem exists with the main spl_autoload functionality if you do not define your own autoloader. > >> 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. > > > > PSR-0 focus on a solid approach of class definition. > > But at the same time it does not touch naming conventions, except for > > file system class locations. > > If you read the mandatory section of PSR-0 [2], you'll see it's pretty > > explicit there this: > > > > - Alphabetic characters in vendor names, namespaces, and class names > > may be of any combination of lower case and upper case. > > > > So anything you said about case-sensitiveness is not broken by PSR-0. > > > Not sure if you understood, or just glanced over it, again. > > I see that your specification _mentions_ uppercase and lowercase > characters. > It falls flat on mentioning any of the implications of their presence > however. > > You see, the only purpose an autoloader has is to map identifiers from > the programming language onto filenames from the operating system. > And there just happen to be functional differences between the two. Namely > identifiers in PHP (like class names) are NOT case-sensitive. But filenames > on the filesystem ARE. And then, on some other systems they ARE NOT. > > This is not even cursorily explained by your specification. The most basic > autoloader requirement of defining an *explicit and dependable mapping* > between the two identifier systems is not met. It only talks about class > names > and namespaces, but declares the translation onto filenames only by > omission. > > Yes, it's obvious that it implies mixed-case filenames. But it seemingly > ignores > that this is a bidirectional dependency. Once you have mixed/fixed-case > files, > you CAN'T have case-insensitive class names anymore. > The current spl_autoload default behavior works on windows great but say you use the default on linux with mixed case file names? It's broken. As it is today in the spl_autoload (default, not custom) we already have a bidirectional dependency. Further what we are talking about here is that there has been a major community adoption. All we are really talking about here is default behavior since you could easily extend such an object to change the behavior of the loading much like spl_autoload. > There's no need to start a discussion about this here, or file subsequent > explanations. There was ample opportunity to do so on the FIG mailing list > after dissident debate has been locked out. Now why the identifier handling > discrepancy never occured to anyone in two years is beyond me. But it's > also irrelevant. > > SplClassLoader anyway does not provide a language-compliant autoloader. > It can fail system-dependent to load class files when the PSR-0 file naming > is followed. > The first instantiation of a class may behave differently from all > subsequent: > > new \Test\UserThing; > new \Test\Userthing; > > Might only work in this order, or the other, or maybe on Win-systems both > cases. > (Again, thanks for not debating coding standards, but PHP language > behaviour here.) > > Much unlike spl_autoload() which defines the only rational mapping. (And > you know, the custom autoloaders of some more contemporary frameworks, > where this very technical side effect was at least discussed.) > This is an untruth. If you read the default source for spl_autoload; if you did not call spl_autoload_register with any values it does search through the include path; it also converts everything to lowercase. See the following bug tickets: https://bugs.php.net/bug.php?id=53065 https://bugs.php.net/bug.php?id=49852 There has been a previous thread on this subject as well (spl_autoload case sensitivity): http://marc.info/?l=php-internals&m=129336968406654&w=3 > If you want to be critic, spl_autoload is a function, from the > > procedural paradigm. PHP does not have the OO implementation for the > > same, so the OO paradigm support is flawed currently in PHP. If you > > look at this perspective, an OO implementation is necessary (this is > > That's a valid reason for inclusion. "Everything is better if you wrap it > in > objects" is baloney, mind you. But a procedural autoloader can represent > more of an obstacle to extension. > But do you have an example handy for SplClassLoader and how/why you'd > inherit from it? Have any of the 18+ frameworks tested their autoloading > with it? (Still concerned about customizing.) > I don't have a handy one, however, if you look at some of the autoloaders in the various frameworks they do have some additional methods that are added on. However, here would be something to mimic spl_autoload's default behavior: MyClassLoader extends SplClassLoader { public function loadClass($className) { parent::loadClass(strtolower($className)); } } Regards, Mike
