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

PHP functions

[spencerogden]

What bugs me about php is how all of the functions are built in. For instance the database access functions are all built in and are specific to the database. I.E. SOmething like mysql_connect() is a function. So not only are your function names long, but if you change backends you have to replace all of your function calls, unless you feel like writing a wrapper for DB stuff. I much prefer perl and CPAN, especially since it makes finding docs very easy.

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

[Anonymous Coward]

Now on to your complaint of long function names. How else should we do it?

Well, it's all about readability so that the compiler takes them out isn't much of a solution.

In VB.NET (i'm not sure if I've got the right name there) there are function names like smtpmail.server="blah" and system.web.session.add("blah"). In PHP these would be smtp_mail_Server = "blah" and system_web_session_add = "blah". The first is easier on the eyes, and more importantly the . isn't used as a whitespace character as in PHP's underscore. The . is a branch like a / through a tree of functions. In PHP you've got one long flat list of functions.

A tree structure of functions in PHP would be nicer.

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:PHP functions

[Anonymous Coward]

s/mysql/pgsql/

Re:PHP functions

[Turmio]

Semi off-topic, but you just can't compare CPAN to PEAR

CPAN and PEAR have nothing in common. CPAN stands for Comprehensice Perl Archive Network. This highly active site is maintained by the Perl community. From CPAN you can find hunderds (thousands?) of Free Perl libraries and corresponding on-line documentation.

PEAR web page says "PEAR is a framework and distribution system for reusable PHP components". So among other things, it acts as an abstraction layer to various RDBM's.

I don't think there's full equivalent to PEAR in Perl world but what the original poster probably meant is DBI - The Perl Database Interface.

Re:PHP functions

[bluegreenone]

You are very correct, it's silly to have such DB platform-specific syntax in the language. In addition to PEAR which others have mentioned there is also John Lim's ADODB, a DB abstraction layer for PHP. It seems pretty robust, check it out.

Re:PHP functions

[CynicTheHedgehog]

Simple solution: use ODBC. Or Java.

Re:PHP functions

[Anonymous Coward]

Considering the way SQL servers simply are not compatible, that isn't a good idea. Look through some SQL an experienced Oracle user uses. Chances are most, or all, of it won't work with PostgreSQL or MySQL. The problem you mention is easily fixed with an awk script. The bigger problem of converting SQL from one DB server to another is not. That's an issue that is much bigger than PHP, and it's something using ODBC or JDBC does not fix.z

Re:PHP functions

[Lordrashmi]

I am not meaning to flame but you can't judge PEAR by its webpage. Most of the PEAR extensions have not yet been documented and put in the pear manual. You can browse them in CVS
http://cvs.php.net/cvs.php/pear
and most have good commenting in them. Also the members of the PEAR-DEV and PEAR-GENERAL lists are very helpful when someone has a question.

While currently the main use of PEAR is the DB class, PEAR will become more and more used as the documentation is improved and developers discover its wonders....

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

Valid XML fragment

[Anonymous Coward]

I'm trying to ensure that what people submit is a valid XML fragment. I also have to use the base PHP compiliation. There is no XML libraries in the base install of PHP for this, so I guess I have to use a regular expression? Or is this too complex for a regular expression?

Re:Valid XML fragment

[StigBakken]

Just add " ... ?>" before your fragment and feed it to xml_parse. See http://php.net/xml.

- Stig

Re:Valid XML fragment

[Anonymous Coward]

That requires features not in the base PHP distro - right? I see that php.net/xml says that this extension uses Expat.

One of the requirements of this software I'm writing is that it works on any php web host and most of those only provide the default. Also, that someone can just grab PHPTriad and install and have working software without having to compile.

Thanks though.

looks like its /.'ed

[krs-one]

The download was VERY slow for me, mirror at php-4.2.0.tar.gz.

-Vic

PHP's Phish release?

[Thing 1]

Inhale...

...

whew! 420, man!

Re:PHP's Phish release?

[emmetropia]

I thought it was a Six Feet Under php release. Chris Barnes is an interactive web app wizard.

new functions / features in 4.2.0

[greywire]

Anybody point in the direction of a list of the new functions / changed functions in php 4.2.0? Particularly the object aggregation functions which dont seem to be in the php manual as yet.

Re:new functions / features in 4.2.0

[Anonymous Coward]

right here man

Re:new functions / features in 4.2.0

[Anonymous Coward]

err ... try this instead

limitations for Mac OS X users... sigh

[ubiquitin]

PHP 4.2.0 still lacks certain features on Mac OS X and Darwin, and isn't officially supported by the PHP Group on these platforms. Building PHP as a dynamically loaded Apache module isn't supported in this release. Well, at least full support is going to happen down the road... it is nice to develop on OSX for deployment on PHP*nix servers.

Re:limitations for Mac OS X users... sigh

[russiste]

yes, PHP support is still lacking a bit from our beloved OS X...

here are some links on the subject that may be of some interest:

http://developer.apple.com/internet/macosx/php.htm l - Apple's PHP page where they "admit" that...

Like all Unix variants, Mac OS X has it quirks. It is also a young OS, and not all Open Source or Unix software projects have had time to test their programs on the Mac and make the necessary alterations

Linked from that last page is http://www.entropy.ch/software/macosx/php/ - a site concerning a prebuilt PHP Apache module for OS X... they are working on the 4.2.0 version and I don't have a doubt that these folks will deliver...!

Installing pre-compiled MySQL, PHP and Graphviz packages on a OS X-running powerbook was a great (and quick!...) experience. May everybody taste the sweet pleasure of writing PHP code on their balcony! :-)

Greg

Apache 2 is EXPERIMENTAL

[dybvandal]

just so everybody knows there is still work done in getting this stuff production ready. Unfortunately there are still issues on both sides (Apache and PHP) and I think apache2+php will not be production ready until php 4.3.0 sometime in august? But there are 2 really dedicated people working on this and I assume they will much appreciate your feedback. So check the latest discussions on php-dev, the bugtracker and test the latest cvs.

Re:Apache 2 is EXPERIMENTAL

[Anonymous Coward]

That's the only reason I wanted to do the upgrade. Everything else works great for me.

Re:Apache 2 is EXPERIMENTAL

[Scooter]

Apache 2 is now the reccomended production release. What is experimental though is PHP's support for Apache 2, and this will be the same story for a number of modules.

I won't consider Apache 2 for production web sites until the PHP guys say "its ready" - as a static web server is no use to me anymore. I do plan to fire up a test server with it though, and the PHP 4.2 support is good news from an evaluation and familiarisation point of view.

external variables

[iguild]

External variables (from the environment, the HTTP request, cookies or the web server) are no longer registered in the global scope by default.

Umm... I'm not sure about others but to me this sounds like a *very* radical change in PHP's behaviour. I updated to PHP 4.2.0 on my server and not a single script worked because PHP simply ignored the variables. For example SquirrelMail didn't even show the login page.

Does someone know how to enable the old behaviour?

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

Re:external variables

[Anonymous Coward]

Yes, the default was changed to off, so if you need this behavior, this needs to be explicitly set.

4.1.0 added some nice new global arrays to make programming a bit easier, and this new default behavior should make people write their scripts a little more carefully.

Re:external variables

[Anonymous Coward]

Someone else said how to enable the old behaviour, but just in case you don't know how to write scripts that get the new variables you need to access $_GET["name_of_variable"] and $_POST["name_of_variable"].

At the release of 4.1 it was said that this way of doing it would be default soon.

Re:external variables

[Anonymous Coward]

The variables are in $_GET, $_POST, $_SERVER, $_COOKIE, $_FILES (http post file uploads), $_ENV (environment), $_REQUEST (variables accessible by users, ie get, post, cookie), and $_SESSION. They're actually quite nice once you start using them.

Too many PHP versions...

[roly]

I don't really see the difference between 4.0.4pl1 (except security holes) and 4.2.0

Re:Too many PHP versions...

[dark_panda]

Well, the changelog between 4.0.4pl1 and 4.2.0 is over 670 lines long. So obviously there have been a few changes since you last checked.

J

Re:Too many PHP versions...

[roly]

yeah, i know. but most scripts still work. however i jus tupdated coz i was boerd.

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.