Re: taking over SQL_Parser

Sebastian, > > i added some patches and some new bug reports including patches I looked over them - they look ok (left 1 comment). > > the big problem is how SQL_Parser handles unknown syntax - it > > should not stop in unknown syntax but extract as much information > > as possible Yes, that's a problem. > without putting pressure on your, ti would be nice if you would come > to any conclusion about getting developer status for SQL_Parser for me Seeing your profile and rank on ohloh.net (you should take over the phpmyadmin cybot user into your account) and the patches, I gave you dev karma and made you lead of Sql_Parser. I already asked the right people to grant you cvs access. > - much documentation 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. > - bringing code to PEAR standards > - putting dialect data files into data? I don't know anything about dialect files :) If they are php, treat them as normal sources. > - renaming Lexer to SQL_Lexer? Using Lexer as class name is a clear violation of PEAR CS, it should be SQL_Parser_Lexer. > ^^ needs this a second package? how should this be handled? I don't think we need a second package, except there are many people interested in having a separate lexer for sql - which I think isn't the case. > - does SQL_Compiler needs a seperate Package? No, since it directly interacts with the structures used by SQL_Parser and is tightly tied with it. > - 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. > - what about tests, can i upgrade them to use PHPUnit 3? Yes, this would be good. > - does anybody knows what was the intention for > Expressions/incldue.php? CVS Log says: Adding a place to hold expressions that I will factor out of Parser.php Factoring seems not to have begun, though. > - package2.xml You can completely drop package.xml v1 support. This said, if you use the roadmap feature of the pear package website, you can generate package.xml files based on fixed bugs automatically. Some closing words: If you think that SQL_Parser needs a refactoring and don't want to keep old legacy code / API, the best thing is to start a new package that supersedes the old one and make it PHP5 only (since this is what the original intention for phpMyAdmin was if I understand correctly). Of course, bugs that can be fixed should be fixed. Welcome onboard. -- Mit freundlichen Grüßen/Regards, Christian Weiske