Re: Contribution for PECL

> > 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. > But it does require a prefix, to be meaningful and unique. > 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"). > Well, as you note PEAR classes are different than extensions. If you have a non-standard extension installed, and you are someone developing a 3rd party application that uses a templating system that uses a (not uncommon) prefix like tmpl_*, the third party application will not run. Once an extension is installed, that namespace is claimed for *all* instances of the PHP interpreter on all scripts. My suggestion would be to give the templating system a name (other than tmpl, template, whatever), and then prefix it with that name. > Anyways if there needs to be a prefix I generally would preefer it to > imply something about the approach "mb" stands for "multi byte" iirc in > the "mbstring" name. mbstring is a bit of a different case, simply because its a standard extension (and most applications don't have their own multibyte functions defined in PHP), therefore it can claim that namespace better. Everyone and there cousins have some sort of messed up templating system (sic.), therefore claiming such a common namespace in a non-standard (non-popular) extension is not the wisest approach. -Sterling