Re: [SQLHat] Proposal

On Tue, Apr 06, 2004 at 03:00:30PM +0200, Lukas Smith wrote: > Well I understand your reasoning. However if I understood things > correct you are parsing the file anyways. So from a Java developer > POV its in no way wierder to be parsing your language compared to > PHP. There by be religous zealot type stuff going on obviously > however. The .sql file is read, then prepared, then processed with the hash of parameters. I see your point, but I'm afraid that religeous/zealot motives are something we should consider when designing such language extensions and that the Java camp might not like the "<?php" tag, the Python and Perl camps would fancy something else and the database camp wouldn't like any opening or closing tags at all and they would be right. > >This is one of my concerns and a reason why I am considering the idea > >to rewrite SQLHat in "C" as a PHP extension. Probably the sql files > >could be cached the way PHP-files are cached. > > Well to me as a PHP developer you are solving a non existing problem > then. I mean to me the solution exists more or less (we are missing > the nice sql file browser) but aside from that all the pieces are > there already .. and assembling them is trivial since its already > part of the language (include that is). The result is far better > than any PECL package you can ever come up with as your solution > would simply not integrate as well (see my bytecode cache example). I understand your POV as a PHP-developer. However, I'd continue looking for a general solution that satisfies various languages developers's needs best. I'm considering the idea to rewrite SQLHat in "C" and as a PHP-extension and this way make it fast and flexible. That might be the solution for using it in Python as well. > Well every language provides its own way of abstracting. Getting > this unified is an amazingly hard task in and of itself, since > abstraction usually means adding overhead or reducing the feature > set. Both if which are essentially very "taste" driven and not so > much sound technical decisions. Each camp has developed its "taste" > and will therefore be weary of outsiders telling them to do it > differently. > > So all in all I found the idea of a browser for those external > ".sql" files very intriguing. The rest of your proposed solution is > solved on the PHP language level already. Whatever you can do is > slower, more cumbersome, less flexible etc. The SQL files's browser is part of the SQLHat's viewer. I'm working on an extension of SQLHat to integrate with prepared statement's concept. I will summarize the reasons why I'd choose not to make SQL files included with include()/require() construct : * The SQL-files should be independent from PHP or any other the programming language and therefore they shouldn't contain tags like "<?php"; * There is no need to use complex constructs in the SQL files beyond the conditional "IF" statement for (not-)including query fragments. Actually you was right that this should be discouraged. Regards, -- Kamen A. TOMOV :. http://www.cybuild.com/ .: