Re: Re: cvs: php4 /pear Mail.php /pear/Mail rfc822.php

> DB_mysql > DB_common > Mail_smtp > > etc... > > What do we want? Renaming the DB classes would be a pain, but if we're going to > do it for consistency, let's do it now. Do we go with first letter of each word > capitalized, with an underscore wherever a directory (indicator of hierarchy) > is? If you have a DB directory, then it seems a bit redundent to have DB_Mysql as the name of an included file - mysql.inc would suffice. Also, I think that we should allow for the possibility that more than one version of a database abstraction layer might resides in the DB directory. For example, I have done some development using PHPLIB's database abstraction layer and there is a possibility that I would move PHPLIB db code (phplib_mysql.inc ?)into this directory for my database abstraction layer. This is not to say I wouldn't use the PEAR (pear_msyql.inc?) version, only that I have some learning already invested in PHPLIB's library and may need to bastardize the PEAR standards to incorporate it into a future project. That, or PEAR standards might move towards the PHPLIB standards so that we could have a happy medium. Speaking of which, it seems like PHPLIB and PEAR are going after the same target. I like some stuff about PHPLIB (clean division of labor among classes, nice short accessors (e.g., $db->query(), $sess->id(), $auth->id)) and I like some stuff about PEAR (more thought devoted to directory structure layout, common error reporting mechanism). I wish we could meet somewhere in the middle so that we would all start porting code into the PEAR project, including code from Manual Lemos' PHP Classes repository as well. Whatever coding standard we come up with, I think it should try to take the best ideas from these three major code repositories of quality code. Also, I think we need to be a bit flexible on coding standards initially unless you think there will be sufficient resources available to rewrite a lot of this accumulated code so that it conforms to PEAR standards. I think a common error reporting mechanism is a good idea, however I think it might be proposed as a target standard for all code, but not necessarily something that we want to achieve right away. Populating the code with accumulated quality code might be the first order of business so that the PHP community starts to view the PEAR project as ONE of the one-stop locations for finding useful bug-tested code for their projects. I just joined this mail list so I apoligize if I am revisiting old issues/wounds. BTW, the way I envision using PEAR is as I am suggesting above. I would probably take its directory structure ideas for arranging the common library code for my sites. I would then stick other useful classes into those directories. I would probably have to ignore some PEAR standards at first so it would be economically feasible to use the library. I would likely only be able to contribute to PEAR to the extent that it was fulfilling some of my immediate development needs, which is how alot of PHP development gets done anyway. Is this how other people see PEAR getting off the ground? Will it expected to be more planned and standardize than this - cathedral or bazaar? Final note: I am partial to having all lower case directory names and script names. I don't like the look of too much mixing of cases (e.g., DB/DB_mysql.inc ). I am also partial to using spaces to separate word tokens in functions names and methods names. My motivation is that I think of a program as a piece of literate writing and in most writing we just have lowercase words separated by spaces (i.e, $cart->get_total versus $cart->getTotal). I think things get confusing once you start thinking about coding as a special case language for expressing yourself (where alot of case mixing and runTogetherWords lead you). I'm flexible however and have coded in different styles. Regards, Paul Meagher