Re: PEAR2 wiki document

On Aug 26, 2007, at 2:42 PM, Gregory Beaver wrote:

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.

Fair enough... Is there a roadmap with timelines on it yet? :-)

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.

Assuming pear.example.com used Example as their namespace. Declaring the namespace would then be a case of modifying channel.xml to include: <name>pear.example.com</name> <namespace>Example</namespace> Once it's discovered, nothing else could use the namespace Example without displaying an error. If a server changed, that would display an error as well. The namespace, which would be kept internally with the channel name, would then just route everything the way an alias does. It would also be the assumption that "pyrus install Example::SomePackage" would be the equivalent in today's PEAR as "pear install example/Example_SomePackage". Again, the assumption is made that Example_SomePackage would be replaced with Example::SomePackage. I'm not sure I see any way to circumvent such a setup without having access to change the internal config/registry files for a given PEAR install. If someone who shouldn't have access to those managed to do that and make changes, there's bigger issues at that point.

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.

Fair enough... Maybe it should be reworded to say something to the effect "exceptions will be made on a case-by-case basis and only after extraordinary evidence is shown to prove that an exception should be made in that case" :-D

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.

I think allfiles needs to be generated. As has been pointed out several times, its easy enough to do programatically, so why add to the developers troubles by making it a required check-in. I'll put together one for phing...

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.

I'm going to have to disagree here. There is an if() that wouldn't normally be there along with an invocation of class_exists() that wouldn't be. class_exists() might be faster than the stat on the file system on some platforms, but there is a performance hit. All that said, I've been coding with an autoloader for the last few months on my pet projects and so far it's working great. -Travis