Re: [PHP-DEV] SplClassLoader and PSR-0 break language semantics
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
Re: [PHP-DEV] SplClassLoader and PSR-0 break language semantics
Hello Guilherme, 2011/10/27 guilhermebla...@gmail.com : > > PHP-Standard list is also opened. ... since a few days. But I'll happily take the discussion there. As I feel it doesn't belong here. Discussing PSR-0 or how it came to be is entirely off-topic (and would be rude). We are just discussing the C implementation now and the effects it would have on PHP core. > > 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. > >> >> 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. 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.) > 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.) > being followed by 18+ widely adopted PHP projects. Which one would you > choose? An individual user suggestion or a group suggestion? Well. I would base the decision *entirely* on technical merits. Though wouldn't rule out popularity or a faux stan
Re: [PHP-DEV] SplClassLoader and PSR-0 break language semantics
On 2011-10-26, Pierre Joye wrote: > On Thu, Oct 27, 2011 at 1:07 AM, wrote: > > 2011/10/26 Matthew Weier O'Phinney : > > > 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. > > Well, my personal opinion here is that you should discuss that in an > open list somewhere and put the RFC together, with examples, docs and > updated patch. The internals list is not really well suited to > discuss that, while I won't mind to have such discussions here, it may > make more sense to have a dedicated list. As it won't be the last > discussion you will have :) The list exists already (http://groups.google.com/group/php-standards), and implementation, RFC, examples, docs, etc. were already debated over 2 years ago, followed by implementations in several dozen projects. What is happening at this point is completion of a C-level SPL class providing a reference implementation that can be re-used directly from the language itself. Even the original code for this was done around 2 years ago; the difference at this point is there is sufficient momentum behind the standard to warrant a push to include it in the language. This minimizes dependencies for projects following the standard, and reduces duplication of effort. The standard is detailed here: https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-0.md I think the only relevant questions at this point are: * Does the implementation follow the specification? * Are there any technical objections that do not counter the specification and which would bar inclusion in the language? -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SplClassLoader and PSR-0 break language semantics
Hi Mario, On Wed, Oct 26, 2011 at 9:07 PM, wrote: > 2011/10/26 Matthew Weier O'Phinney : >> >> 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. PHP-Standard list is also opened. Anyone is able to contribute there too. We are requesting here is a standardization that was made between more than 18 well recognized PHP projects as a community request, not as an individual request. Anyone is able to open a new PR to official FIG (Framework Interoperability Group) repository[1] and start a new standard recommendation. If it'll ever be proposed to be accepted by core, it'll depends on how well it'll be accepted by PHP projects. > > > 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. We have proven that it's possible to have some PHP standardization. Symfony 2, Zend Framework 2, Doctrine 2, Drupal, PPI, FLOW3, Typo3, and many other projects have successfully adopted a single and unique implementation of what we refer as PSR-0. This answers your question about wide adoption. Every implementor of PSR-0 have its own PHP implementation, either because of license restrictions, CLA, etc. But the implementation is almost the same (there're very few exceptions of docblocks and code indentation). We all love and propagate the re-usability principles, and as I previously exposed, PSR-0 is already a common code shared by many widely adopted projects. So why not keep in a unique place? Initially, it may sound like "ok, so open a GIT repository and everyone uses it", but the fact is that a native C implementation is much faster than a PHP implementation, and we're willing to contribute with the language that all of us work on daily. > > 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.? Already answered before. Performance is important. A native C implementation is much faster than a PHP code implementation. > 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.) You missed the point. PSR-0 was untouched for over 2 years, without a single local customization. Of course the FIG board identified enhancements (such as multiple folders per namespace and multiple autoloading namespace addictions in a single class loader), but the kernel operation is untouched since its definition in 2009. The standardization of OO PHP code remains the same between all these project. It's proven to work, and it's proven that a standard can be reached in PHP, a language that is suffering so much by the lack of standardization. It may sound a bit offensive, but PHP has 10 ways to do the same thing, which opens so many possibilities that lead to so many bad code out there. > > 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.) Any ms is important in a request. You may tell it's all framework's fault, but the support they provide, the amount of internal specific optimizations they made is so much that if you'd have to implement your own with same support, it'd take years and the performance would never be the same. We're here to talk about PHP standardization, not about code bloat in frameworks. Do not loose focus. > > >> 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.) It seems you have a personal feeling about this proposal. It's not a 1 man work that one, but rather a 20+ people. So forget about "can of worms". That proposal (PSR-0, which the RFC is entirely based on) was discussed for almost an year, inspected a huge range of projects and have been approved by 18 people. Of course we may have missed somethi
Re: [PHP-DEV] Re: is_a() - again - a better fix
On Thu, Oct 27, 2011 at 12:00 PM, Jan Schneider wrote: > I'm going to check with our Jenkins guru, but I'm wondering how such a VM > should look like. Should it contain a complete Jenkins instance, or just a > checkout of the Horde packages that you would run from your own Jenkins > server(s)? It will be no different to what you have now to run the tests locally. All we need is a result set (json) that will be pushed in our servers and displayed, alerts will be sent on errors, etc. Are you online somewhere for a chat? -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: is_a() - again - a better fix
Zitat von Pierre Joye : hi Jan! On Wed, Oct 26, 2011 at 11:16 AM, Jan Schneider wrote: On Tue, Oct 25, 2011 at 12:13 PM, Ferenc Kovacs wrote: from a quick look on their setup, they only have one node, and they are using the global php binary, so no, they are only testing one php version, and I don't think that it would be the snapshot. but that would be cool. :) Ferenc is right, this is testing against the distro's latest version. It is sadly not very useful for us, while being informative. To know that something went wrong when a release is already out is too late, let alone when the distros updated their package :) Sure, this was just to showcase the number of tests that we already run continuously to find regressions in *our* snapshots. It is a must and it is what we need to do. We don't have the resources to run such a node on our own. The idea was to provide the test suite of the most recent package releases for such a snaphot testing machine (run by the php group?) Do you have some time to setup the tests script in a VM? Then we will use what we have already to run php's snapshot and RCs. We will share VMs for 2-3 projects. I'm going to check with our Jenkins guru, but I'm wondering how such a VM should look like. Should it contain a complete Jenkins instance, or just a checkout of the Horde packages that you would run from your own Jenkins server(s)? Jan. -- Do you need professional PHP or Horde consulting? http://horde.org/consulting/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
