PHP 4.2.0 Released

emmetropia writes: "PHP 4.2.0 has been released, with experimental Apache 2 support, and lots of other improvements and fixes. Check it out!"

Comments

PEAR DB

[Anonymous Coward]

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

[tenman]

what about the XMLDB libs? please don't come out of the box ditching on PHP cause you can't think of anything better to slabdown to get the phirst post. PHP 3.0 requiered libs to connect to any database, and now supports plenty of the nativly to help techno weenies adopt the platform. But just because the authors wanted to make language easy to use, doen't mean that it not still a powerful force. You can still mod and lib the engine, and you can still tweek the install configs where it beats the pants off of an asp server. You won't hear me talk bad about the 4.0, and I don't want to hear you talk bad about it eather.

Re:PHP functions

[fdragon]

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.

Re:PHP functions

[Fweeky]

Yeah, it's a bit ugly having a flat namespace of, let's see;

-<freaky@voi:~/src/phpdoc/en/functions>-
-% grep '<refentry id="function\.' *.xml |wc -l
2579

2579 functions.

Although I can see the argument for having all the compiled-in extensions loaded all the time, having absolutely everything in the same namespace makes writing procedural code a little dangerous, not to mention leaving a nasty taste in your mouth if you're trying to code in an OO fasion.

The answer is, of course, to put your functions in a seperate namespace (a class in Zend 1, a proper namespace in Zend 2), or to use a naming scheme that's less likely to conflict (personally I use WordCaps (or camelCase) instead of under_scores, but since PHP doesn't stick to under_score style all the time and isn't case sensitive, this isn't a wonderful solution).

Coding in an OO fasion's less an issue for namespace conflicts, and more an issue for getting procedural code thrown in everywhere unless you load performance draining wrappers. PHP's weak object model doesn't help here. After using Ruby I find myself running into PHP's limits a lot harder. *grumble*

I hope that they will move extensions to make use of namespaces sometime (PHP 5, or 6 maybe); i.e. MySQL::connect(), PgSQL::connect(), etc. If nothing else this will help make the language cleaner.

BTW, as for CPAN, some of the PHP bods are trying to produce something like it; PEAR, which includes a passable database abstraction layer, among other things.

Personally, I'd be using Ruby if it had better webserver embeddability (mod_ruby doesn't yet support Apache 2, and the Apache 1 support feels a bit immature) and a nicer CGI API. Running it as a daemon might be an interesting solution, but finding hosts who will allow that might be a bit of a pain. Maybe I should try it out while I can :)

Re:new functions / features in 4.2.0

[Anonymous Coward]

err ... try this instead

Re:external variables

[Skip1952]

Don't know if this will help but I had to put the following in the php.ini file:

register_globals = On

Database Abstraction Problems

[einhverfr]

Database abstraction on the language level poses some real problems. For example:

1: PostgreSQL's result set is not forward only. This can be helpful sometimes. Most others are.

2: Interbase stores table names in upper case.

3: Timestamp formats vary per rdbms, and some other aspects of SQL syntax do as well (; or go, for example).

4: MySQL has no equivalent of roles.

I much prefer to work with a database abstraction layer which is a set of function libraries, yet still have the option of rewriting them to take advantage of the unique features of a given database. I can then wrap the behavior of the rdbms' which don't conform.

There are many OO and non-OO database abstraction schemes out there. I have even written my own which is tuned for abstraction and performance and so is procedural rather than OO. But my point is that this allows greater freedom and flexibility.