Re: taking over SQL_Parser

Sebastian, > > (you should take over the phpmyadmin cybot user into your account) > what? where? into which account? http://www.ohloh.net/accounts;search?q=cybot I assumed that your account is the one with karma 1, and your phpmyadmin cvs commit account is the one with karma 10. > > Documentation is done in peardoc/ cvs module. We use docbook which > > can be hard to get into first, but I'm happy to help you. > ok, but phpDocumentor doc is missing everywhere - shouldn't this be > there also? They are there: http://pear.php.net/package/SQL_Parser/docs links to autogen API docs on the right. > >> - putting dialect data files into data? > > I don't know anything about dialect files :) > > If they are php, treat them as normal sources. > yes, they are PHP, but containing only arrays > shouldn't there be only Class definitions in this strcuture? Good question. I personally am fine with both, you could do a SQL/Parser/Dialect/<type>.php > > No, since it directly interacts with the structures used by > > SQL_Parser and is tightly tied with it. > but SQL_Parser_Compiler? Yes. > >> - what about ctype.php? is this the correct way to handle possible > >> missing functions? > > If you need to use functions that are not available everywhere, you > > normally use PHP_Compat package. If this doesn't provide the > > functions, either do it yourself (such as the package did), or > > contribute to it. > ok, so it is fine to have such a file ctype.php there? Yes, as long as it gets installed into SQL/Parser/ > so i should not 'convert' this package to E_STRICT compatible? > even this package was created before 2007-01 but it has never left > 'devel' status I didn't see that it's devel. So you're free to make it PHP6-strict :) -- Mit freundlichen Grüßen/Regards, Christian Weiske