RE: [PEAR-DEV] Contribution for PECL

> -----Original Message----- > From: Sterling Hughes [mailto:sterling@bumblebury.com] > Sent: Saturday, December 28, 2002 2:42 PM > To: Lukas Smith > Cc: pear-dev@lists.php.net > Subject: Re: [PEAR-DEV] Contribution for PECL > > > Wow, I don't understand several things in this thread. > > > > 1) Why does he have to find some meaningless prefix? Is this a new rule > > for all packages? I understand that when we have two packages that > > compete we must find a solution to the naming clashes this might create. > > But I say its tough luck for the package that comes second. Because we > > never know when it does or if it will ever come. > > > > Well, the idea of a good naming convention is not saying tough luck to > either package. In pear there is the concept of top-level package names > and then subsequent sub-classes. Even library authors (in the general C > sense) will most often prefix the function calls with something relatively > unique, I don't think it should be different here. tmpl_* is too "common" > for me, and I don't think that in general it should be claimed by a PHP > extension (I would be giving this advice were it not to be accepted as a > PECL library, but now that is, well, my opinion is all the more > relevant ;-). > I liked the idea of max, etc. simply because then you have a unique naming > convention, something that most likely will not be claimed in people's > code > as a standard CS term. There is nothing in PEAR/PECL for all I know that forces you to add "meaningless" prefix to make possible future name classes unlikely. As far as I know even the non "core" php extensions don't have any such prefixes, nor do PEAR packages that have no competition. Moreover it is common practice that the package/extension that comes second has to worry about that. Like "MDB" because it came after "DB" .. I don't have a good example for a php extension atm (and I am too lazy to think of one ... hmm maybe "mbstring"). Anyways if there needs to be a prefix I generally would prefer it to imply something about the approach "mb" stands for "multi byte" iirc in the "mbstring" name. Regards, Lukas