Re: merging Controversial changes back into PEAR2 Standards

On 2007 09 22 18:48, Gregory Beaver wrote:

Hi all, I would like to take a quick straw poll to gauge your approval or disapproval of the controversial changes currently separate from the PEAR2 standards. How do you feel about merging the controversial changes back into the official PEAR2 coding standards proposal? Please respond to this question with +1 for "strongly agree" 0 for "don't care either way, and "-1" for "strongly disagree." Anyone may vote and all opinions have equal weight. The straw poll will be used to determine how to proceed, and is simply intended to check on how we've done with improving the proposal to address concerns raised when it was originally proposed and after. Links: http://wiki.pear.php.net/index.php/Controversial_Changes http://wiki.pear.php.net/index.php/PEAR2_Standards Basically, these three things would again become part of the PEAR2 coding standards and community standards proposal: * eliminate require_once/include_once/require/include from PEAR packages as a means of loading classes, and instead rely upon users to either use PEAR2_Autoload or a customized loading solution of their own creation * recommend using class_exists() to throw an exception with helpful error message when loading drivers [this is optional, and would be a recommendation, not a requirement] * use import statements at the top of the file to declare dependencies explicitly An update is probably also in order with regards to namespaces in PHP. Namespaces will be a part of PHP 5.3, and multiple namespaces will be allowed per file, although the syntax of multiple namespaces in a file is still being debated. PEAR2 does not allow multiple classes per file, and so the resulting syntax is irrelevant to the standards, but the performance difference (as we know) is significant between a single file and multiple files. Having the option to combine PEAR classes into a single file may be important for uber-performance freaks. All standards adopted with regards to namespaces will of course bend to the final implementation of namespaces as the language feature develops. However, the coding standards proposed that mention namespaces are based upon non-controversial implementation features of "namespace" and "import". A brief explanation of the import statement and how it works with autoloading is in order. First off, if the engine encounters a statement like this: <?php namespace Brrrr; Foo::bar(); ?> * If "Brrrr::Foo::bar()" exists at compile-time either as namespace Brrrr::Foo with function bar() or as class Foo in namespace Brrrr with method bar(), then it will resolve to that (in that order - function before class, so class Brrrr::Foo would need to be called explicitly with ::Brrrr::Foo::bar() or with an import statement). * otherwise, resolution is done at runtime in this order: 1) check to see if Foo exists in namespace Brrrr and use it if so 2) check to see if there is an internal class named Foo 3) use autoloading This ordering means that this code can be a problem: <?php namespace PEAR2::Package; throw new Exception('blah'); ?> if PEAR2::Package::Exception doesn't already exist, the "Exception" class will be thrown instead. The solution is to use an explicit import for all classes defined in external files (external dependencies) like so: <?php namespace PEAR2::Package; import ::PEAR2::Package::Exception; throw new Exception('blah'); ?> Now, PHP treats the file as if you had written: <?php throw new ::PEAR2::Package::Exception('blah'); ?> This also has the benefit of being a compile-time substitution, which makes the code both slightly faster and easier to cache in an opcode cache. So, this is the primary reasoning behind the 3rd recommendation. Namespaces and autoload is tremendously complex to understand, so I would be happy to try to answer any questions raised by this, and will pass on the ones I don't have answers for to the implementors of the patch, Dmitry and Stanislav. Thanks, Greg

1) +1 2) +1 (how can you -1 a recommendation, can't see the problem with this). 3) 0 Would be a +1 but for the @uses requirement in doc headers. Can't phpdoc parse the imports and do this on its own?