Re: PEAR2 package naming standards (namespace usage)

Joshua Eichorn wrote: > This is the end of this topic for me, I will be taking people's concerns > into account as I updated the rfc and make sure it has more examples and > is clear. > > On to specific concerns: > Multi-level namespaces lets me type less: > If you are going to create an instance more then once then use as is > always less typing. > If you are only going to create a single instance then the full path at > that point is always less typing. > > Also if a package has you creating hundreds of instances by hand then > there is a problem with the package design. > > SVN is a 3rd party program and shouldn't be a concern in the design: > SVN is how we are managing code in pear2, and hopefully soon in all of > PHP. It and tools with similar rules like git is how the open source > world manages code. Correction: Pyrus is how PEAR2 manages its code. svn/git is secondary. This is like saying PEAR1 manages its code with CVS. I still feel that the new RFC introduces far more complexity than is either necessary or helpful. I think we see why the original design of PEAR1 decided not to go with the same structure in CVS as at installation. Might I ask what problems have we encountered in PEAR1's naming scheme that warrant this? We have yet to have a single conflict of naming that I can think of, and it is in fact *not* recommended to run code straight out of CVS or SVN. I understand that Travis has mentioned that Phing does this naturally, but unless we are replacing Pyrus with Phing, there is very little incentive to go this route. For once, I agree whole-heartedly with Alexey :). One obvious example of a use case that is no longer possible with the proposed RFC. If a package is re-factored in order to split off classes into subpackages, this would in fact break BC with the new RFC and is therefore forbidden. Why? Let's say a user is extending a driver, which used to be in: pear2::my_package::driver::MySQL and is now split into its own package. This results in a new class name: pear2::my_package_mysqldriver::Driver so our poor user's code: <?php namespace MyNamespace; class Mydriver extends pear2::my_package::driver::MySQL {} ?> suddenly results in parse error class not found. Before anyone argues "that's bad class design" let me remind you that the entire point of using a scripting language like PHP is that we can decide later to quickly re-factor and redesign. The proposed RFC puts up an unnecessary barrier to this natural process. It is ultimately irrelevant whether you think what I am suggesting is good or bad design, it is something that has been very successfully done with PEAR1, and is one of the things that is possible with Pyrus/PEAR Installer because of its superior remote dependency handling. I, fortunately, am not a member of the PEAR Group or your president any longer, so I speak only as a developer with a strong opinion here :). Greg