PEAR DB
by
Anonymous Coward
·
· Score: 4, Informative
There is always the PEAR DB abstraction layer: http://pear.php.net/manual/en/core.db.php
No need to write the wrappers yourself
Re:PHP functions
by
fdragon
·
· Score: 4, Informative
Have you taken a look at PHP 4.x's equiv to the CPAN yet, PEAR?
Using PEAR I have items such as database abstraction, PHPDoc (JavaDoc for PHP basically), and much more.
Sure it is a layer on top of what is available but if you combine this, with APC or Zend you can precompile everything to byte code for faster execution.
Documentation for php is also very easy to find. You have it available for download in HTML, TXT, Windows CHM, and PalmDOC formats. All of this is also available online fully searchable with comments from the users.
As for your complaint about the built in nature of all the database access functions, how else would you do it? Generate.so/.dll libraries for the functions so you can update them later? (This is already done.)
Now on to your complaint of long function names. How else should we do it? Use something cryptic like hungarian notation so we end up with a function that looks like "pidbcm" for returns a pointer to an in and i am a database connect function for MySQL? Personally I don't find a problem with identifiers up to 50 characters long so long as they define what the identifier is. The compiler will take them out anyways.
-- The program isn't debugged until the last user is dead.
Re:new functions / features in 4.2.0
by
Anonymous Coward
·
· Score: 4, Informative
There is always the PEAR DB abstraction layer: http://pear.php.net/manual/en/core.db.php
No need to write the wrappers yourself
Have you taken a look at PHP 4.x's equiv to the CPAN yet, PEAR?
.so/.dll libraries for the functions so you can update them later? (This is already done.)
Using PEAR I have items such as database abstraction, PHPDoc (JavaDoc for PHP basically), and much more.
Sure it is a layer on top of what is available but if you combine this, with APC or Zend you can precompile everything to byte code for faster execution.
Documentation for php is also very easy to find. You have it available for download in HTML, TXT, Windows CHM, and PalmDOC formats. All of this is also available online fully searchable with comments from the users.
As for your complaint about the built in nature of all the database access functions, how else would you do it? Generate
Now on to your complaint of long function names. How else should we do it? Use something cryptic like hungarian notation so we end up with a function that looks like "pidbcm" for returns a pointer to an in and i am a database connect function for MySQL? Personally I don't find a problem with identifiers up to 50 characters long so long as they define what the identifier is. The compiler will take them out anyways.
The program isn't debugged until the last user is dead.
err ... try this instead
Don't know if this will help but I had to put the following in the php.ini file:
register_globals = On
== Shipwrecked and comatose