Hi List!
Eg for my Parser The prefix could be either PMAsqp_ or PMA_SQP_ (I'd go for the second one, as it is still compliant with the PEAR naming conventions
Right, the second one is a good choice IMHO.
As things stand, I have been using PMA_sqlParser_* for functions specific to the parser PMA_str_* for functions dealing with strings and PMA_* for functions not directly specific to the parser (the character type matching for example).
OK for "PMA_SQP_" in place of "PMA_sqlParser_" but why having a prefix for string function?
From seeing your work, I've made most of the changes in my own codebase with the suggestions from the list.
Fine :)
Loïc
______________________________________________________________________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP... http://www.ifrance.com/_reloc/email.emailif
On Tue, 23 Jul 2002, Lo�c wrote:
PMAsqp_ or PMA_SQP_ (I'd go for the second one, as it is still compliant with the PEAR naming conventions
Right, the second one is a good choice IMHO.
Done.
As things stand, I have been using PMA_sqlParser_* for functions specific to the parser PMA_str_* for functions dealing with strings and PMA_* for functions not directly specific to the parser (the character type matching for example).
OK for "PMA_SQP_" in place of "PMA_sqlParser_" but why having a prefix for string function?
They are heavily used with the parser, but they are not part of the parser. They have a much broader scope in terms of what they do, which is why I wanted to put them seperately.
Additionally, there is one thing I was going to be doing with them for speed reasons. If the 'ctype' extension is available, then there are high speed C versions of nearly all of these functions, which should be used instead. This is the other reason for the indirection. If the extension is not available, then just use my PHP versions of the functions.
-
Lo�c -
Robin Johnson