Re: PEAR2 wiki document

On Aug 26, 2007, at 9:43 PM, Gregory Beaver wrote:

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.

The current system of <suggestedalias> is like your namespace tag, but allows the user to "import" a namespace through the "pear channel-alias" command and is in fact closer to the idealized namespace implementation than your proposal ;). Seriously though, I am not convinced there is a compelling reason to change this system to make it more restrictive.

Ok - I'm trying to think up a way to remove some duplication. You could install pear2/HTTP_Request, but then when that file is located in PEAR2/HTTP/Request.php there's a disconnect to me.

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...

Sounds fine to me. I would prefer that the packager generate it if one doesn't already exist, or if requested. Phing as an option for packaging would be interesting to some folks (if you want to write it and maintain it).

I would like to move the packager portion out of pyrus all together (seems like we've had this discussion). Adopting something like phing with an official build.xml template to work from adds a ton of flexibility and moves part of the complexity of pyrus off to another system.

This leads me to believe that perhaps class_exists() is not a solution, and the only solution that is both flexible and fast is the doc comment at the top of the file needs to document where to find required classes, and the coding standard should be updated to reflect this.

I'm for this - with pyrus being able to scan for dependencies. Maybe something along the lines of 'pyrus check Example::Package'. At any rate, I have a generic annotation parser that I would be happy to contribute to PEAR2 to help get that going... -T