Re: PEAR2 wiki document

Re: Namespaces and package names: I'm not thrilled with mixing _ and ::. Using PEAR2_HTTP_Request to install PEAR2::HTTP::Request doesn't make sense to me. I would much rather see it as pyrus install PEAR2::HTTP::Request. I'm not sure I see the reason to use underscores in place of double-colons within the name other than BC which PEAR2 hasn't been worried with thus far. On another note, what about incorporating a channel level namespace into the installer? Channels currently serve as a faux-namespace, but if we have real ones couldn't we remove the pear.example.com from the beginning and replace that with the fully declared namespace? This being the case I think we'll need an organization outside of PEAR to serve as a registrar for namespaces within PHP land to help avoid any namespace conflicts, but that's a topic for another discussion. Re: Class to file naming exceptions: I'm not a fan of any exceptions to the rule - I just don't see a need for anything installed in @php_dir@ to not following Example/Package/Class.php naming. If there's a valid case where that exception should live, I'm happy to listen. Re: Loading all files at once: I would remove the dirname(__FILE__) in favor of a package level constant. If NS'd constants can be declared with functions in them (a la define()), then I would at an Namespace::Package::path = dirname(__FILE__), then use "require Namespace::Package::path . '/Class.php';". If namespaced constants go the way of class constants, then I would follow the Super_Long_Package_Name convention and specify that each package should define "Example_Package_path" (or some similarly named constant) to avoid the repetitive dirname(__FILE__) calls. Re: if(!class_exists('SomeClass', true)) Is this a requirement that they be declared at the top, or just a suggestion for people who want to add them? In the tests that I ran back in June, it appeared that the if statement ate up a large chunk of the benefit of not doing require_once everywhere. I would be for making this a suggestion for people interested in documenting, or provide some sort of annotation in a docblock that can be checked by pyrus, phing, etc. I think as I continued reading through the proposal that it appears optional. That would definitely be my preference. Note: Sorry if some of this seems incoherent. This email has been written in a half dozen sittings, so the thoughts may appear more jumbled than normal for me ;-) -Travis On Aug 24, 2007, at 9:27 PM, Gregory Beaver wrote:

Hi all, I've made some significant revisions to the wiki based on some of the complaints and a few exciting developments in the PHP language itself. The revised document is at http://wiki.pear.php.net/index.php/PEAR2_Standards As a reminder, PEAR2 is intended to be a giant leap forward, and so we're still feeling our way around in the darkness of possibility. Any proposed changes can be negotiated, although I hope that we can be more civil than in the last iteration which was a complete nightmare. This was due to an unfortunate combination of people being on vacation, incompletely thought-out ideas, and abject terror on the part of those who would be subjected to those ideas. I promise to focus on making the incomplete ideas work, and I trust you to understand that I may not fully understand what makes them incomplete until you provide me a perspective I have not seen yet. Highlights: * require the use of namespaces, and the minimum PHP version to support these (most likely 5.3.0, although we will know for sure when 5.2.4 is released in a week or so) * rewording of introduction to explain better the goals - further work will be done to explain the problems that are being solved, probably in a separate document * clarification of allfiles.php to show alternative syntax may be used if the result is the same * note added to the data files handling section to expect changes based on a proposal I emailed to pear-dev today * Extensive rewording of the commit policy for collectives, explaining that although commit access will be allowed for all collective developers, it is still expected that committing will function very much like it does today - with lead developer permission except in exceptional circumstances. This shifts more control back to developers while still opening things up. * Extensive rewording of the package design section to also give developers more control than the original wording * Added a note to the move from alpha->beta for a package saying that package names are available on a first-come-first-serve basis. * Added notes to the potential problems section so we don't forget them. Please let us know if this helps to address some of the concerns raised. There is a LOT more work to be done, but I would like to know if this is a step in the right direction. Greg --PEAR Development Mailing List (http://pear.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php