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

Quoting Paul Meagher <paul@datavore.com>: > 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. mysql.php, you mean. =) But take a look - that's already the case. > 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. Why wouldn't you give it a different top-level directory? > 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. This is a nice idea. > 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. Okay. What are the best ideas from PHPlib and the classes repository? I'm not aware of any standards associated with the classes repository, and I'd moved away from phplib even before I found PEAR because I thought I could do things better. So get down to specifics: what do you like about phplib that you want to see in PEAR? > 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. This is one way to look at it, but if we do that first, and then rewrite all the code, we're going to frustrate all the people who started using the code before it was changed, since we'll have broken their scripts. > I just joined this mail list so I apoligize if I am revisiting old > issues/wounds. To some extent, yes. Unfortunately I don't think anyone has managed to get this list archived yet, so I can't tell you to go read up. :) I'll see about doing that... > 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? I believe that projects - and PEAR is no exception - need one or a few strong forces (individual people, most likely) driving them at the start to get them underway as something coherent. It'd be nice if PEAR's standards made everyone happy, but that's impossible. I think PEAR _will_ attract more developers and users, though, if it is built up carefully and consistently. But if we just talk about how to do things forever, nothing will get done at all. > 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 ). Do you have any reason for this besides that you don't like the look of it? Below you argue in favor of natural-language like legibility; eliminating capitals seems rather contrary to that idea. > 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. This is one of those old discussions. We've pretty much adopted the Java style of naming methods. Everyone won't agree on one or the other, and I see nothing in your argument - which basically amounts to your personal preferences, and however well thought out they are, they are still your preferences, and different from other peoples' - to change from the standard that we already have. -chuck -- Charles Hagenbuch, <chuck@horde.org> "If you can't stand the heat, get out of the chicken!" - Baby Blues