Re: [SQLHat] Proposal

From: Date: Tue, 06 Apr 2004 13:00:30 +0000
Subject: Re: [SQLHat] Proposal
References: 1 2 3  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-27088@lists.php.net to get a copy of this message
Kamen TOMOV wrote:
Using PHP would also allow for some more complex things inside the files, which should probably discouraged, but will ensure that you dont suffer from any limitations from some custom scripting language (which right now only does parameter replacements and if's it seems (?)).
Actually it's not a custom scripting language - it's a hat, SQL's hat :) Yes you're right I have only "IFs" there in addition to parameter definitions. This pseudo-code, even if a reason to extend it shows up, should stay closer to SQL than to any other language and that is an additional reason why I wouldn't decide to use more complex PHP or other syntax inside the .sql files.
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.
Beyond that there would be the advantage of reducing the overhead as normal PHP files would also be cached using standard PHP bytecode caches (remember that reading files is not an insignificant overhead otherwise).
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).
As a matter of fact I was also considering the idea to suggest to the database managers's producers like MySQL, PostgreSQL or Oracle to adopt the idea but it seems not very likely that all they would do so. That's why I need SQLHat independant not only from the programming language but also from the database.
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. regards, Lukas Smith smith@backendmedia.com _______________________________ BackendMedia www.backendmedia.com berlin@backendmedia.com Linn Zwoch Smith GbR Pariser Str. 44 D-10707 Berlin Tel +49 30 83 22 50 00 Fax +49 30 83 22 50 07

« previous php.pear.dev (#27088) next »