Re: PEAR2 wiki document

Travis Swicegood wrote: > 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. This bothers me as well. Namespaces as a possibility is so new, I would like to reserve judgement on this one, we will have a number of months left before the first alpha release of pyrus when the decision must be made. > 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. This was considered for PEAR 1.4.0, and it turns out that having a channel name that is different from the channel server introduces a whole new level of potential security vectors, as it then becomes possible to trick the client-side installer into thinking the server for a channel has changed. As such, this will never be considered as an option. Channels do not function as a namespace for code, only for packages, and as such have been working brilliantly, one of the few features that as yet no one has complained about (until now :). I also don't follow what a "fully declared namespace" would look like in channels, perhaps you can elaborate. > 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. No one is a fan of it, but allowing a case that no one has thought of to be specially approved by a vote of the governing body of PEAR provides a loophole that means we are stringent but not inflexible. In other words, it makes it very easy to adhere to name=>file rule, and very annoyingly hard to get an exception. > 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. You can do whatever you like in allfiles.php, this is in the language. It is a black box that after including has loaded all needed files. > 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. If the file is already loaded, there is no performance difference. Greg