[PEPr] Comment on RFC::Package naming, file naming and directory structure RFC

Greg Beaver (http://pear.php.net/user/cellog) has commented on the proposal for RFC::Package naming, file naming and directory structure RFC. Comment: In general, very good. The directory structure section should be completely stricken from the proposal. I will vote -1 if it is still in there, so be forewarned. A reference to the pre-existing document should be used instead. Redundancy in this case is bad, and I'll tell you why :). I have been running into serious difficulty creating applications that conform to these directory conventions. There are several situations in which the data directory must be a subdirectory of the php directory, such as a web application containing images, and other examples that are even more complex (configuration data is separate from image data). There are magic ways to make this happen, but I suspect that when PEAR goes application-friendly, the first thing to fall will be the strict directory conventions. New roles will need to be introduced to handle tasks, etc. Mandating directory structure now will only impede this eventuality. I would however, revise the class/file question of interfaces. Interfaces should be 1 interface per file, in a subdirectory named "Interface" This way, we get names like PhpDocumentor_Interface_Parser for the interfaces, which are very clear. I believe that namespace pollution is a non-issue. As each package is proposed, the best name will be agreed if there are no restrictions except for duplicate names. This means that if a package is best named Template_Smarty that's great. If it is best named Refrigerator, that's great, no need for unnecessarily long names like Refrigerate_Things. Note that channels will reserve an entire namespace (if a channel named Grop is registered, any package prefixed with Grop_ will not be accepted into PEAR because it would conflict with Grop package names). I'm not sure if it is better to add this now or wait until channels are complete (I've almost finished the PEAR package implementation, pearweb is next). If the fixed category repository thing is implemented as described, I will also vote -1. I would like to see this worded as: "If possible, you must use a category prefix that already exists in PEAR. It is not OK to propose a package named DataB_DataObject_Handler, for instance, but DB_DataObject_Handler is an acceptable name. If you feel strongly that a new category prefix is needed, be prepared to defend it." I do think a list of category prefixes already used should be available on the PEPr page, that would be very useful for fledgling developers. I think the description of package names you have come up with is great. I believe it is a fantastic guideline, but would be a terrible mandate. Communal common sense should determine a package name, and there will be cases where "but it has to be XXXX_YYYY because of the rules" will simply cause an inferior name to be chosen. These guidelines will help proposers choose the best name prior to proposing. I would recommend shortening the text to the shortest possible wording as well: Package names should be descriptive English, and avoid abbreviations wherever possible. A package name must be unique within PEAR, and consist of a valid PHP class name (letters and underscore). The shortest name possible should be chosen, but no shorter. "Games" is too general, "Games_Chess" is better. If your package has specific output, prefix with the output type, as in "HTML_TreeMenu." If your package is similar to other packages already in PEAR, choose a name that identifies this similarity. A package that deals with XML processing should prefix with XML_ as in "XML_XSLT_Formatting." A package name should have no more than 3 alphabetic segments separated by underscores. "One_Two_Three" is OK, "One_Two_Three_Four" is not. Sub-packages consist of the main packages name followed by an underscore and the subpackage name, as in DB_DataObject's subpackage DB_DataObject_FormBuilder. I do believe that there are logical exceptions already in the repository. XML_Serializer and XML_Unserializer, for instance. Separating these into different packages makes no sense whatsoever. XML_Serializer_Unserializer is simply confusing. PEAR's goal needs to be to make it *easier* to understand what is going on, not harder. This is why these must be guidelines to filter out trash prior to package proposal, and not hard and fast rules. That's all I have right now. Greg Proposal information: http://pear.php.net/pepr/pepr-proposal-show.php?id=55 -- Sent by PEPr, the automatic proposal system at http://pear.php.net