Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

PHP 4.3.0 Released

michael posted more than 11 years ago | from the choice-of-a-new-generation dept.

PHP 243

aftk2 writes "PHP.Net has just reported the release of PHP 4.3.0. The update sports a unified method of handling files and sockets, a bundled GD library (for working with images), and finalizes PHP's command line interface. For other information, check out the ChangeLog."

cancel ×

243 comments

Sorry! There are no comments related to the filter you selected.

PHP 4! (-1, Offtopic)

Real World Stuff (561780) | more than 11 years ago | (#4968314)

Who gives a damn...Friday Burn Yada Yada...BTW it ain't you

Nice (1)

HowlinMad (220943) | more than 11 years ago | (#4968330)

I like the bundled GD library.

Re:Nice (2)

drightler (233032) | more than 11 years ago | (#4968391)

Thankfully you can still use a non-bundled GD with the GIF support patch.

Re:Nice (-1, Troll)

Anonymous Coward | more than 11 years ago | (#4968397)

I LIEK PIE

YUO SUCKS

Perl is obsolete! (-1, Flamebait)

Anonymous Coward | more than 11 years ago | (#4968355)

Andrew Tanenbaum told me so!

That's great (5, Insightful)

Karamchand (607798) | more than 11 years ago | (#4968356)

Thanks go to the PHP team for all this great work!! :-)

It's a pity though that Apache 2 support is still experimental. I hope the Apache and the PHP team get the work done fast so that Apache 2 can spread faster! :)

Re:That's great (1, Informative)

Anonymous Coward | more than 11 years ago | (#4968511)

The reason for this is that many of the PHP extensions are not thread-safe, and could have unexpected behavior when running under Apache 2's multi-threaded model. If you're on UNIX and you wanna use Apache 2 & PHP, use the Worker model. It's the traditional multi-process model.

Re:That's great (2, Informative)

MmmmAqua (613624) | more than 11 years ago | (#4968564)

Actually, the prefork MPM module is the old 1.3-style model. Worker is a well-known threading model wherein a "boss" thread delegates work to a pool of "workers" and queues work requests when all workers are busy. Of course, it's more involved than that, and there are several sub-models of the Boss/Worker model, but you get the point.

Re:That's great (1)

rollthelosindice (635783) | more than 11 years ago | (#4968565)

At least they have it in a better state than Mod_perl for Apache 2.

Re:That's great (2, Interesting)

ajayrockrock (110281) | more than 11 years ago | (#4968838)

The last time I asked about apache2 support on the #PHP IRC channel, someone told me that the apache2 api is still a moving target and that's why it's taking so long for php to be "stable" on apache2.

I can't wait to use Apache2 but I need PHP support to be stable before I can upgrade.

later,
ajay

Why I prefer PHP to Perl (-1, Troll)

egg troll (515396) | more than 11 years ago | (#4968366)

Hello Slashdot,

Recently I've had a chance to do some web design with PHP. Previously I'd used Perl because I'd heard from many people that Perl was the end all and be all of scripting languages for the web. Imagine my suprise
to discover that PHP was vastly superior! I know this is a bold statement, but I have solid arguements to support it.

Before I begin, let me just clarify something. I'm not arguing that PHP is better than Perl in all cases. There is certainly still a use for Perl. Also, PHP isn't perfect but it does manage to fix many of the shortcomings I've had with Perl. Here are a few of the things I've noticed about PHP. Finally, I'm not the most talented Perl programmer out there. I generally prefer to use the vastly superior Python, but can use Perl if I have to.

* Ease of use. After about a day I had an excellent understanding of both PHP and SQL. I was able to get a stable, useable and presentable website up within 24 hours of reading the basics of PHP. Learning Perl
took me weeks and I'm still not even as good with it as I am with PHP. I would definitely not recommend anyone new to programming begin with Perl.

* The OO of PHP is excellent. In my experience, it rivals Smalltalk. We all know that Perl's OO still needs work (whether or not OO is all that great is another discussion.) Hopefully Perl will be patched up so it supports such must-have OO features like introspection, reflection, self-replication and ontological data-points.

* Outstanding database support. PHP supports virtually every DB under the sun (although Berkeley DB is missing, oddly enough.) Perl seems limited to MySQL and PostgreSQL, and its really a kludge for the later. I've heard that this will be fixed in upcoming versions of Perl though.

* Speed. PHP is one of the fastest languages I've ever used. While it won't be replacing assembly or C, its definitely faster than Perl in almost every case, particularly in regex which has long been Perl's
strongest point. I'm sure there are cases where Perl is equal to PHP, but I can't think of any at the moment.

* Portability. I can take PHP code off my Linux box and plop it onto an IIS server, or even one of those new Macintosh servers and have it run without having to change a single line of code. Try doing this with Perl! Its as though it was written in assembly, Perl requires
that much rewriting.

* Graphics. PHP comes with a nice little graphics library. While I wouldn't use its to code the new Doom (VB would be a better choice) its adequate for most web pages, and should be considered as a substitute for Flash for certain things. Perl lacks a graphics library
of any kind.

* Data Structures. Under PHP you can create any type of datastructure you need: Linked lists, binary trees, hash tables, queues, inverse Reiser-biased recursion trees, etc. Under Perl you're extremely limited in what you can do. This is because Perl isn't OO (so you can't create Node classes, for example, usefull in a linked list) and because it lacks pointers. Some of you may notice that PHP lacks pointers, but look deeper! Behind the scenes, hidden from the user pointers are used. Because of this, PHP can support complex data
structures.

Again this is just my experience. I don't mean to offend any Perl coders because Perl was an excellent language. However, in certain cases it may behoove one to write the back end in PHP instead of Perl.

Thank you for your time,

Egg Troll

Re:Why I prefer PHP to Perl (-1, Offtopic)

Real World Stuff (561780) | more than 11 years ago | (#4968382)

Hello ET...Long Time. How is the family? Finally put down that mangy dog?

the secret to a +1 bonus (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#4968392)

If egg troll can do it, anyone can.

The real secret is to keep a library of ready-to-paste comments handy.

Copy, paste, collect points.

Re:Why I prefer PHP to Perl (2, Offtopic)

The-Perl-CD-Bookshel (631252) | more than 11 years ago | (#4968406)

This is great. A Perl troll used to get +4 in a PHP discussion. Take a bow.

Re:Why I prefer PHP to Perl (2, Informative)

SweetAndSourJesus (555410) | more than 11 years ago | (#4968409)

Haven't I heard this somewhere [google.com] before?

Yes! (0)

Anonymous Coward | more than 11 years ago | (#4968474)

And who was the author of that litlte gem recently posted to USENET? :)

Re:Why I prefer PHP to Perl (1)

keiferb (267153) | more than 11 years ago | (#4968747)

Yes... It's one of the more interesting posts to come across alt.chinchilla in ages.

Re:Why I prefer PHP to Perl (1)

drightler (233032) | more than 11 years ago | (#4968414)

./configure --help
<snip>
--with-db2[=DIR] Include Berkeley DB2 support
--with-db3[=DIR] Include Berkeley DB3 support
</snip>
There is Berkeley DB Support.

Re:Why I prefer PHP to Perl (0)

Anonymous Coward | more than 11 years ago | (#4968482)

Please mod up: +5, Insightful. The poster captures my feelings poignantly.

Re:Why I prefer PHP to Perl (2, Informative)

jmertic (544942) | more than 11 years ago | (#4968509)

* The OO of PHP is excellent. In my experience, it rivals Smalltalk. We all know that Perl's OO still needs work (whether or not OO is all that great is another discussion.) Hopefully Perl will be patched up so it supports such must-have OO features like introspection, reflection, self-replication and ontological data-points.

How is this? PHP's OO is weak and kludged together ( but will be much better come Zend 2/ PHP 5 ).

I'm not sure if either (a) Smalltalk is horrible ( which from my understanding isn't ) or (b) the parent should be modded +1 Funny. Seriously, putting PHP in the same OO ranks as Smalltalk is like putting a Ford Escort in the same offroad handling ranks as a F-150 truck.

On a side note, is it just me or is /. really slow right now?

Re:Why I prefer PHP to Perl (1)

InfiniteWisdom (530090) | more than 11 years ago | (#4968754)

On a side note, is it just me or is /. really slow right now?

I think they're being Slashdotted.

Re:Why I prefer PHP to Perl (5, Funny)

Anonymous Coward | more than 11 years ago | (#4968540)

While I wouldn't use its to code the new Doom (VB would be a better choice)

*ROTFL*

Ahh, an excellent post. I'll give you a solid B+.

But, if I may give you some advice. The VB comment gives you away. You must make your trolls highly subtle, even more so than they are now. They must balance lightly on a fine edge between Trolldom and NonTrolldom. People in a hurry should be able to scan your message and be 100% convinced you are an idiot, and have no idea you are really in control. Then they will post, and when the troll is discovered, THEY will look like idiots, and you will be revealed as a genius because of your gentle entrapment. This is the true genius of a troll. To ensnare and to incite the unwary.

One metric I use in my own efforts is the dynamic of up/down moderations. A "perfect troll" should look like this:

  1. First the comment should be modded up +3 or +4 insightful immediately, since your post will no doubt be long, and in the early stages, all long posts are considered insightful because nobody bothers to read them.
  2. Next, people who disagree with you will come by and mod it down to +1 flaimebait (a few humourless souls will actually mod it as a troll).
  3. Next, people who get the joke will come and raise it to +3,+4 funny. Now your Troll is gaining steam.
  4. It should waffle about between Troll and Funny for several minutes, hours if you're good. Hitting zero is a bad sign, your post might get lost. If this happens, you made your troll too inflammitory.
  5. When things settle, you should have "total=16" or better in the mod point summary.
  6. Finally, it should stablize at +4 funny. +5 means you made the joke too obvious. +4 is perfection. If you make it this far, congratulations!

I wish you luck in your further efforts.

Re:Why I prefer PHP to Perl (2)

mstyne (133363) | more than 11 years ago | (#4968592)

Good lord, go outside.

SHUT THE FUCK UP, MORON (0)

Anonymous Coward | more than 11 years ago | (#4968597)

You will not get laid through trollbusting on Slashdot. Definitely not with a condescending attitude.

Re:Why I prefer PHP to Perl (2)

glwtta (532858) | more than 11 years ago | (#4968580)

Excellent troll all around, well done. I especially like the points about database access and data structures.

Of course you forgot to mention PHP's new command line mode which makes it more versatile than perl. The vast resources available from CPHPAN, and more specific projects, such as BioPHP. And PHP's tighter integration with client side DHTML technologies such as JavaScript, CSS, DOM and XML which allow you to do DHTML natively in PHP.

Re:Why I prefer PHP to Perl (2)

Christianfreak (100697) | more than 11 years ago | (#4968644)

Well since someone modded up the troll I suppose I should reply to it.

* Ease of use.

I started with Perl, I was writting web pages in a day with it. Maybe it depends on the teacher.

* The OO of PHP is excellent. In my experience, it rivals Smalltalk. We all know that Perl's OO still needs work

I use PHP, I have yet to see a reason to do much OO in what is primarily a web scripting language to embed in an HTML page. What I have seen seems incomplete and difficult to use. Contrast to Perl which while it may not be as feature complete as say Java or Smalltalk it is certainly easy to use and I think it has the right principles behind it. Especially after Perl 5.6. As far is PHP being as good as Smalltalk at OO, I have my doubts but I can't say for sure as I don't program in Smalltalk.

* Outstanding database support. PHP supports virtually every DB under the sun (although Berkeley DB is missing, oddly enough.) Perl seems limited to MySQL and PostgreSQL, and its really a kludge for the later. I've heard that this will be fixed in upcoming versions of Perl though.

This is simply untrue, Perl supports tons of databases through the DBI (which is also fairly simple to write new drivers for if you need them) and even if there isn't a native DBI driver, DBI supports ODBC and you can use any database that has it. That's certainly far more than just MySql and Postgres. I think your description of databases in Perl fits better for databases under PHP especially before PHP 4.

* Portability. I can take PHP code off my Linux box and plop it onto an IIS server, or even one of those new Macintosh servers and have it run without having to change a single line of code. Try doing this with Perl! Its as though it was written in assembly, Perl requires
that much rewriting.


FUD. It depends on what you do. Last I saw Perl has been ported to every major platform except Palm. Contrast to PHP which is on what Linux and Windows? Okay maybe some other Unixes. Perl is on dozens of Unixes, OS/2, Windows, MacOS (Before OSX), and I even had a friend using it on VMS and I also think there's even a DOS version. Some networking features used to have issues on windows but that's been fixed now with emulation

* Speed. PHP is one of the fastest languages I've ever used. While it won't be replacing assembly or C, its definitely faster than Perl in almost every case, particularly in regex which has long been Perl's
strongest point. I'm sure there are cases where Perl is equal to PHP, but I can't think of any at the moment.


If your using if for administration scripts and text processing I don't know if Perl is faster or not, but for that sort of thing I doubt there is enough difference to care and i can't imagine how annoying it would be to try writting that sort of thing in PHP. (That's just personal preference though) ... On the web PHP beats a CGI script written in Perl because PHP is normally compiled into the server. Using mod_perl fixes this problem and gives you the power of Perl with equal or greater speed... I'm not going to say one is faster than the other because benchmarks are very subjective. Finally as I understand it, mod_perl scales better.

* Graphics. PHP comes with a nice little graphics library. While I wouldn't use its to code the new Doom (VB would be a better choice) its adequate for most web pages, and should be considered as a substitute for Flash for certain things. Perl lacks a graphics library
of any kind.


More FUD: How about OpenGL [cpan.org] or maybe the GD library [cpan.org] (which is what PHP uses). Oh yeah there's even a Gimp Perl interface [cpan.org] . Not to mention SDL tie in and several others. In fact if you go to CPAN Search [cpan.org] frontpage there is a link that says "Graphics" which lists several common ones.
The fact that these are not in the core language is a good thing. PHP's braindead way of putting everything_in_the_same_namespace() gets really old.

* Data Structures. Perl has references which can point to sub routines, arrays hashes or other contants or scalars. You can also muck around with the underlying GLOBS and there are a bunch of B::* modules for mucking around with internals as well. I certain that you can probably accomplish the same things using those tools. However even if you can't when do you need that sort of thing in a website? I think that if I need a data structure that complex I'll write it in C.

IMHO PHP will be good when the developers stop dumping one hacked subroutine after another into the core of the language. When they fix interpolation which is a nightmare (works sometimes and other times doesn't???), when new versions quit breaking existing code and when they build in better support for system wide modules and add ons.

If Perl has nothing else it still has CPAN [cpan.org] nothing PHP has even comes close to the amount of add-ons and extras that are easy to find and just work.

Re:Why I prefer PHP to Perl (0)

Anonymous Coward | more than 11 years ago | (#4968709)

Why I prefer PHP to Perl: Its so damn easy that i was making $30/hr wiring enterprise level apps with it how many know perl and do that?

Re:Why I prefer PHP to Perl (2)

slamb (119285) | more than 11 years ago | (#4968698)

Please mod the parent down. I don't want to see this crap. I'm surprised people fell for such obviously wrong statements from someone named "eggtroll". I try to refrain from calling people trolls when there's any doubt, but there's none here.

* Ease of use. After about a day I had an excellent understanding of both PHP and SQL. I was able to get a stable, useable and presentable website up within 24 hours of reading the basics of PHP. Learning Perl took me weeks and I'm still not even as good with it as I am with PHP. I would definitely not recommend anyone new to programming begin with Perl.

That's a nebulous statement. I think Perl is not a hard language to learn. Furthermore, I don't see anything in this post that leads me to believe eggtroll has ever used either language, so this isn't even good anecdotal evidence.

* The OO of PHP is excellent. In my experience, it rivals Smalltalk. We all know that Perl's OO still needs work (whether or not OO is all that great is another discussion.) Hopefully Perl will be patched up so it supports such must-have OO features like introspection, reflection, self-replication and ontological data-points.

Perl's OO support does need work. But it does support introspection. (Reflection is another term for introspection.)

Real problems with Perl's OO: it does not statically check anything. It does not enforce encapsulation. It feels like a kludge in general to me. From what I've been reading of Perl 6, I think it will be much better. I'm looking forward to it.

Self-replication? Ontological data-points? These are not OO terms.

I do not use PHP, but I would be shocked if its OO support rivalled SmallTalk's. You'd need to provide a lot of evidence for me to accept that.

* Outstanding database support. PHP supports virtually every DB under the sun (although Berkeley DB is missing, oddly enough.) Perl seems limited to MySQL and PostgreSQL, and its really a kludge for the later.

I regularly use Perl with Oracle. There are many [uwinnipeg.ca] different database drivers.

* Speed. [...] Its [sic] definitely faster than Perl in almost every case, particularly in regex which has long been Perl's strongest point.

I assert otherwise. Prove it. In fact, I think PHP uses the PCRE - Perl-compatible regex library, intended to be like Perl's but somewhat less complete.

* Portability. I can take PHP code off my Linux box and plop it onto an IIS server, or even one of those new Macintosh servers and have it run without having to change a single line of code. Try doing this with Perl!

I do regularly, with success.

* Graphics. [...] Perl lacks a graphics library of any kind.

Wrong. It has image libraries [uwinnipeg.ca] and windowing libraries [uwinnipeg.ca] .

* Data Structures. [...] Under Perl you're extremely limited in what you can do. This is because Perl isn't OO (so you can't create Node classes, for example, usefull in a linked list) and because it lacks pointers. Some of you may notice that PHP lacks pointers, but look deeper! Behind the scenes, hidden from the user pointers are used.

Perl has references. As in Java, they are essentially safe pointers with automatic memory management (though the GC is less sophisticated). And it does have OO support, at least to the extent required to make a Node class. There is no limit to the data structures possible in Perl.

Perl has its flaws, but these are not they.

I'm waiting for php.NET (0, Funny)

Anonymous Coward | more than 11 years ago | (#4968367)

when's that due?

Re:I'm waiting for php.NET (1)

neverkevin (601884) | more than 11 years ago | (#4968641)

it looks like it already is, php.net [php.net] , where else would you download it from? :)

Re:I'm waiting for php.NET (2)

Karamchand (607798) | more than 11 years ago | (#4968658)

Hey, it works already! Just try it: Open your brows^WMicrosoft Internet Explorer and type php.NET.
Great, isn't it? ;)

But does it have the Power (2, Funny)

YellowSnow (569705) | more than 11 years ago | (#4968372)

To eliminate duplicate Slashdot posts

Re:But does it have the Power (1, Offtopic)

whiteranger99x (235024) | more than 11 years ago | (#4968386)

To eliminate duplicate Slashdot posts

Not really, the tools they use are only as good as the editors themselves ;)

Re:But does it have the Power (1)

anarchima (585853) | more than 11 years ago | (#4968992)

Not really, since Slashdot is written in Perl...

Shit. (0, Redundant)

Dark Lord Seth (584963) | more than 11 years ago | (#4968375)

Another two hour compile coming up for my dual p100 :( I want two bloody p233 mmx instead, that ought to speed the whole thing up a bit...

Incidently, kudos for adding in the GD image library. Though people will still need appropriate libraries for jpgs, pngs, etc, as far as I know.

wow (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#4968438)

I seem to be caught in a time warp, are we suddenly back to 1996 again?

Re:wow (1, Offtopic)

Dark Lord Seth (584963) | more than 11 years ago | (#4968504)

No, 1994 actually because that's when my server was built. I got it cheaply on some online trading site. Don't forget I'm a student, so I must keep an eye the budget. Besides, it's not like a SMB/HTTP/NAT server requires allot of proc power, does it?

Re:Shit. (0)

Anonymous Coward | more than 11 years ago | (#4968831)

Cant you afford $2 for a damn duron 1100??

PHP... (0)

Anonymous Coward | more than 11 years ago | (#4968376)

almost object oriented.

good job fuckheads (-1, Troll)

Anonymous Coward | more than 11 years ago | (#4968384)

you killed opera. you bastards.

you asshats fucked up your html so badly,
opera would rather shoot itself in the
head than attempt to render it.

quite an accomplishment, I'd say.

Best New Feature (5, Interesting)

The-Perl-CD-Bookshel (631252) | more than 11 years ago | (#4968385)

Is the friendly error messages [php.net] , they point you back to the PHP Documentation [php.net] . Being a regular in #PHP IRC channels, this is going to save me a lot of headaches :) Praise the lord, the newbies have fully automated RTFM messaging!!

Re:Best New Feature (-1, Troll)

Anonymous Coward | more than 11 years ago | (#4968929)

Great- another clusterfart idiot that thinks that you can develop a clean architecture with PHP.

Piping Hot Penis 2.5 (-1)

neal n bob (531011) | more than 11 years ago | (#4968395)

A new release from Jon Katz pants is also available. Supports for Commodore 64 and Mac OSX only.

PGSQL support problem? (3, Informative)

DragonMagic (170846) | more than 11 years ago | (#4968403)

I'll have to recheck this later, but I installed PHP 4.3.0 on a Cobalt RaQ3 over a PHP 4.2.3 install using the same configuration line, simply adding the GD install flags. The PostgreSQL make errored out on the install, when it was compiled in 4.2.3 without a problem. Took it out of the configure line, and it installed fine.

I really do enjoy having Postgre and MySQL support on the same machine, but for now I guess I'll have to stick with MySQL until I figure this one out.

But above all, CONGRATS on the changes, PHP team, and please keep up with the good work! It's a great software and a great asset to server administrators, programmers and scripters around.

Re:PGSQL support problem? (0)

Anonymous Coward | more than 11 years ago | (#4968515)

I just compiled with mysql, pgsql, and interbase support with no problems.

Re:PGSQL support problem? OT (1)

lor3 (194957) | more than 11 years ago | (#4968933)

Second time typing this due to powercut!!!

I had a similar problem on my raq3 with the CVS snapshots (I haven't tried 4.3.0).

I assume you're trying to work with pg7.x... The problem is that php links to the pg6.x libs if they're installed, and therefore fails because it uses pg7.x headers.

You can either uninstall with pg6.x libs, which will break the cobalt web config thing (not sure if that's such a bad thing. Anyone with a way to completely automate a deb/gentoo install on a raq3 please let me know!). The other way is to temp. mv the pg6.x libs from /usr/lib while u make/install php.

pg6.x libs are /usr/lib/libpq*
run ldconfig after moving them from and to the libs dir.

And that's it. Good luck.

built for the web? (0, Troll)

ufoo (635711) | more than 11 years ago | (#4968412)

Why is it that the echo command requires one to escape quotes if PHP is "built for the web?" That has always intrigued me as a fundamental usability flaw.

Re:built for the web? (1)

pig-wfa (636843) | more than 11 years ago | (#4968607)

how else would you deliniate?

Re:built for the web? (2)

The-Perl-CD-Bookshel (631252) | more than 11 years ago | (#4968633)

Umm... You don't have to escape a double quote if you use a single quote around the echo. However, if you want to include variables ($foo) then you will have to use the double quotes and yes escape them. I don't see this as a usability flaw, its just the way it has to be for the interpreter to read what your trying to program. Would you rather it try to guess what you are trying to accomplish; Or would you rather make PHP harder to learn by using obscure charicters around echo statements?

Re:built for the web? (2, Informative)

bdesham (533897) | more than 11 years ago | (#4968638)

Why is it that the echo command requires one to escape quotes if PHP is "built for the web?" That has always intrigued me as a fundamental usability flaw.
The echo command only requires users to escape double quotes when they are placed inside double-quoted-strings:

echo "PHP is \"built for the web\".";
and
echo 'PHP is "built for the web".';

do the same thing, although the second form is preferred by most because it uses less overhead.

Re:built for the web? (2)

rycamor (194164) | more than 11 years ago | (#4968746)

Even more fun; you can use the Perl 'heredoc' format, in which you don't need to escape either set of quotes:

echo <<<END_OF_STRING

anything you 'want' here, except the "token" above,
including $variable interpolation, even with some
nice ${embed}ding methods, even with some more
{$complex->expressions()}.

END_OF_STRING;

(http://www.php.net/manual/en/language.types.s tring.php#language.types.string.syntax.heredoc)

Re:built for the web? (0)

Anonymous Coward | more than 11 years ago | (#4968653)

You only need to escape quotes if you're double-quoting. For instance, to say: I said, "Hello.":

echo "I said, \"Hello.\"";
or
echo 'I said, "Hello."';

Re:built for the web? (1)

FireChipmunk (447917) | more than 11 years ago | (#4968742)

Or you can use this.....
echo END
"built for the web?"
END;

personaly I find it much better that screwing with " '

Re:built for the web? (2)

Arethan (223197) | more than 11 years ago | (#4968923)

You only need to escape quotes that are the same as you are using to encapsulate the sting literal to begin with.

For example:
echo "this is an "example" quote"; //wrong
echo 'this is an "example" quote'; //right
echo "this is an \"example\" quote"; //right

echo 'this is an 'example' quote'; //wrong
echo "this is an 'example' quote"; //right
echo 'this is an \'example\' quote'; //right

It's actually better than ASP IMHO. ASP requires you escape all double quotes, since that is all you can encapsulate strings in to begin with.

Dynamic extensions for MacOSX (1)

ravemax (452708) | more than 11 years ago | (#4968446)

Finally dynamic loaded extensions are supported on MacOSX.

Re:Dynamic extensions for MacOSX (2)

Daniel Dvorkin (106857) | more than 11 years ago | (#4968550)

Anyone who's had luck building on this on OS X, could you help me out? I get a bunch of "undefined symbol" errors and the message:

make: *** [libs/libphp4.bundle] Error 1

at the end of the make process.

Re:Dynamic extensions for MacOSX (2)

Daniel Dvorkin (106857) | more than 11 years ago | (#4968666)

Okay, I'm an idiot -- kind of. I figured it out about thirty seconds after I posted, but the reason why still kind of puzzles me. Basically, it appears you have to build it with either the --disable-dynamic or --disable-static option. It just doesn't want to build both versions at the same time. I can kind of see why this is the case (I mean, that's why I guessed at it) but it does bother me a bit that it's not in the documentation anywhere. It may be OS X - specific, but even so, it's a pretty big problem.

Command Line Interface? (-1, Flamebait)

Burgundy Advocate (313960) | more than 11 years ago | (#4968452)

A freakin' command line interface?

Amazing. While MS continues to innovate visual solutions to problems, the open-source community keeps returning to outdated ways of doing things.

Why didn't they spend all that time in a better way -- say, creating a nice, point and click interface? If they don't, developers will be forced to upgrade to a feature-full language like ASP, which has a full, elegant visual interface.

The idea that you should have to learn the command line interface to a language will end up coming back to bite PHP it the ass. I don't want to be forced to use ASP. Please, would you guys reconsider?

Re:Command Line Interface? (2)

Mitchell Mebane (594797) | more than 11 years ago | (#4968505)

Uh, I think you missed the point. PHP now has the potential for much broader use a a general shell scripting language, instead of mainly as a server-side web scripting language

uh (2)

SweetAndSourJesus (555410) | more than 11 years ago | (#4968522)

The command line interface [zend.com] enables you to run php scripts from the command line, that's all.

I'm totally unclear regarding your "point and click interface" dilemma. Are you talking about visual php editors [zend.com] ?

Anyway, I agree that someone like you is probably better off with a "full-feature" language like ASP. Dig that full, elegant interface!

Re:Command Line Interface? (1)

akac (571059) | more than 11 years ago | (#4968579)

What the heck are you talking about? I use PHP on Windows and Mac OS. There is no command line interface to it. Its a scripting language. I write my code in DreamWeaver and BBEdit, but I do the same for ASP. ASP.NET has a great visual IDE, but most of the time is spent in the code editor - writing ascii text. So my experience with DW MX for PHP and VS.NET for ASP.NET is about the same.

Re:Command Line Interface? (3, Informative)

soundofthemoon (623369) | more than 11 years ago | (#4968587)

While MS continues to innovate visual solutions to problems, the open-source community keeps returning to outdated ways of doing things... The idea that you should have to learn the command line interface to a language will end up coming back to bite PHP it the ass.

Not sure if this is a troll or just a misfire. The optional CLI is an addition to PHP, not something that changes how you use it from web pages. The CLI is a valuable feature. It lets you use PHP as a shell scripting language, rather than being restricted to CGI processing.

Using the CLI, you can write a wrapper that dumps a PHP-created web page to a static HTML file. Now you can use PHP as an authoring tool for statically served web pages. Nifty!

In a related note.... (5, Informative)

Davorama (11731) | more than 11 years ago | (#4968473)

...this just came in to my inbox. PEAR at version 1.0. Good job folks!
The new PEAR package PEAR-1.0 (stable) has been released at http://pear.php.net/.

Release notes
-------------
* set default cache_ttl to 1 hour
* added "clear-cache" command

Package Info
-------------
The PEAR package contains:
* the PEAR base class
* the PEAR_Error error handling mechanism
* the PEAR installer, for creating, distributing
and installing packages

Related Links
-------------
Package home: http://pear.php.net/package-info.php?package=PEAR
Changelog: http://pear.php.net/package-changelog.php?package= PEAR
Download: http://pear.php.net/get/PEAR-1.0.tgz

Authors
- ------------
Stig Bakken <ssb@fast.no> (lead)
Thomas V.V.Cox <cox@idecnet.com> (developer)
Martin Jansen <mj@php.net> (helper)

PHP and GD (-1, Troll)

Anonymous Coward | more than 11 years ago | (#4968494)

Damn acronyms... PHP, GD Giddy giddy pooh! If there will be more acronyms around me you can FYMA and FTYFTFEFAD and FFO!

Re:PHP and GD (1)

RetroGeek (206522) | more than 11 years ago | (#4968553)

And this from an AC ....

Apache 2.0 friendly (0)

josephgrossberg (67732) | more than 11 years ago | (#4968500)

If I'm not mistaken, this is the first ".0" release optimized for the new Apache server.

PHP and Apache 2.0 documentation [php.net]

never mind (1)

josephgrossberg (67732) | more than 11 years ago | (#4968523)

oops ... if this post is accurate [slashdot.org] , it appears I misunderstood.

Re:never mind (2)

Karamchand (607798) | more than 11 years ago | (#4968668)

Well, of course 4.3.0 is more "optimized" for Apache 2 than the previous version, but as said before it is still marked as experimental. Just look at the PHP 4.3.0 release notes [php.net] .

XML? (2, Interesting)

King of the World (212739) | more than 11 years ago | (#4968521)

One of the problems I'm having is that there's no way in the standard PHP build to deal with XML. I either have to treat it as a string and write regular expressions (which, as anyone who knows the regexp xml problem, isn't reliable) or build my own with some external xml library, meaning that as I want to allow others to use my code I have to get each user to recompile too (which is like asking people to recompile their kernel, some will do it, some won't, and there's _usually_ no good reason why it had to happen in the first place).

Does this release change what's bundled in the base XML support? They mention function call changes but usually those functions are useless without a recompile.

PHP is still mostly a web page language. XML support should be just bread and butter to it. I need it to deal with RSS or RDF. I need it to deal with user input (if I want to do XHTML I don't want a user typing posts that are malformed - right now I have no way of knowing that).

//

Php has strip_tags() which, naturally, strips tags from a string. But as there's little functional difference between tags and attributes it seems strange that I'm unable to strip attributes with as easy a syntax (yes, I have to use regexps again).

//

I hope this doesn't sound too down on PHP. It's a good language. It's just not a great language like Java or .NET (lets face it, OO in PHP isn't great, and that's what most people have been waiting on PHP 4.3 to fix)

Re:XML? (3, Informative)

DragonMagic (170846) | more than 11 years ago | (#4968605)

PHP can be configured for XML support, but I've seen PHP move from HTML to XHTML support instead. One thing I'd love to see is a way for an install-level configuration for using XHTML or XML on PHP output. Also, yes, the striptags and htmlentities and such will barf on XML codings, and there should be better support for this, hopefully in 4.4.0

Re:XML? (1)

King of the World (212739) | more than 11 years ago | (#4968661)

That's the problem though, that being "configured" for PHP means that I can't use any of the PHP hosts out there, and its certainly more difficult to configure PHP on a Windows OS :(

Re:XML? (0)

Anonymous Coward | more than 11 years ago | (#4968772)

GD could be configured too, but now it's standard because they understand that being in the base distro has social advantages. Why not XML too?

Re:XML? (2)

Randolpho (628485) | more than 11 years ago | (#4968608)

You should consider switching to the Zope [zope.org] platform. Although XML parsing is not yet out-of-the-box in Zope, there are several products for the platform available free of charge that should do what you want it to do.

Re:XML? (1)

FamedLamer (322029) | more than 11 years ago | (#4968619)

I do not understand your comments or how they relate to the article.

Agenda pushing?

Re:XML? (1)

King of the World (212739) | more than 11 years ago | (#4968690)

Well, I'm talking about the limitations I hit when I try to write in PHP. It's been this way for years now with no great changes. I'm not sure whether others want these fixed or if -- although present in other languages -- they're generally unused. 4.3 was supposed to be the OO release, and it seems that on Slashdot OSS problems are only discussed when a problem is solved. Here are some more problems I've experienced. Meh.

Re:XML? (2, Informative)

HarrisonFisk (624200) | more than 11 years ago | (#4968813)

PHP has built in support for expat XML parser [php.net] The parser has come with PHP since PHP 4.0 Beta 4.

There also is a nice wrapper called XML_parser [php.net] in PEAR. That package is installed by default in PHP 4 I believe.

If you are going to deal with RSS and RDF stuff, then I definately recommend you check out the PEAR XML_RSS package [php.net]

I see nothing lacking with PHPs XML support.

Re:XML? (1)

King of the World (212739) | more than 11 years ago | (#4968938)

I said "there's no way in the standard PHP build to deal with XML", and those PHP functions you mention require the external Expat libraries, right?

Why doesn't PHP break off MySQL and Postgres support into optional libraries? Just recompile with some command line options and include the library in your php.ini. The feature's there, so why complain about mysql and postgres support? What's included by default is important.

They see mysql and postgres and db2(!) as required features that would just be annoying to have to bother getting to work. They don't see XML as a required feature yet. Doesn't that strike you as weird?

silly (probably) question (2)

glwtta (532858) | more than 11 years ago | (#4968541)

I haven't used PHP much in some time, but I remember it using GD years ago - what exactly was added in that regard?

Re:silly (probably) question (1)

pig-wfa (636843) | more than 11 years ago | (#4968590)

I believe it is now a standard component instead of an optional add in.

Re:silly (probably) question (2)

DragonMagic (170846) | more than 11 years ago | (#4968820)

On Windows, libgd was installed by default, but on *NIX and other platforms, you had to install all the libraries to support GD, and then install GD, and then configure PHP for GD support. With 1.6, 1.8 and 2.0 versions, many things did not work properly between all these versions on *NIX systems, compared to Windows PHP. Plus there were some bugs that couldn't be worked out in PHP because they were in the GD code.

To make it more compatible cross-platform, get a unified libgd version to use, and add functions not normally found and fix bugs, PHP has added GD as a bundled extension. This is a good thing.

April's fool day? (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#4968548)

In some coutries April's fool day is tomorrow! December 28th. Be carefull!

Just an Observation (0)

Anonymous Coward | more than 11 years ago | (#4968574)

article:
The update sports a unified method of handling files and sockets, a bundled GD library (for working with images), and finalizes PHP's command line interface.

Please note that this is the only time you will see the words sports and PHP in the same sentence.

- TBS

Student suspended over suspected use of PHP (5, Funny)

happypizzaguy (325415) | more than 11 years ago | (#4968576)

I thought this [bbspot.com] might apply here. Hypertext preprocessors are pretty dangerous. Everyone use 4.3.0 with caution.

consider running an opcode cache (4, Informative)

Kunta Kinte (323399) | more than 11 years ago | (#4968581)

Most server side scripting engines nowadays employ opcode caching. Code is compiled the first time executed, but run from memory the rest of the time.

This is different from HTML output caching.

Opcode caching is said to increase performance by 30-200% depending on the cache code you use and your app.

With about 30% of apache installs running PHP, and with more than 50% of the web running apache, I'm surprise the PHP does not include an opcode cache with the install.

That's a lot of wasted cpu cycles :) Just compiling PHP scripts on every page hit.

There are open source caches out there, see the link in my sig.

Re:consider running an opcode cache (1)

drightler (233032) | more than 11 years ago | (#4968682)

I would wager to say that PHP doesn't come with an opcode cache because Zend [zend.com] would like to charge for theirs.

Re:consider running an opcode cache (0)

Anonymous Coward | more than 11 years ago | (#4968744)

True dat. Zend are kinda holding PHP back. PHP Accelerator (they have a .co.uk) is the alternative but it's not OSS.

Maybe this proves that the OSS business plan of making money from surrounding products should be managed more carefully. That PHP still doesn't include it is strange.

Re:consider running an opcode cache (1)

Second_Derivative (257815) | more than 11 years ago | (#4968794)

Anyone have any experience with APC [communityconnect.com] ?

Re:consider running an opcode cache (4, Interesting)

MmmmAqua (613624) | more than 11 years ago | (#4968710)

Why no official PHP Opcode cache [weblogs.com]? 30-200% performance gain

Simply asked, simply answered: there is no "official" PHP opcode caching because PHP relies on the Zend engine and the PHP developers work very closely with the people at Zend, who sell the Zend Performance Suite [zend.com] (formerly Zend Accelerator), and the guys at PHP are not about to cut into Zend's livelihood by bundling a product with PHP which makes the Zend product redundant.

Re:consider running an opcode cache (3, Interesting)

Kunta Kinte (323399) | more than 11 years ago | (#4968919)

Simply asked, simply answered: there is no "official" PHP opcode caching because PHP relies on the Zend engine and the PHP developers work very closely with the people at Zend, who sell the Zend Performance Suite

That's the main answer I'm hearing. But zend is very expensive.

Maybe there's a compromise. How about a modest PHP opcode cache that has only some of zend's features; ie. a little bit slower and more conservative than zends.

I appreciate the work the zend guys have done, trust me I do. But that's an important feature to leave out.

Re:consider running an opcode cache (3, Interesting)

glwtta (532858) | more than 11 years ago | (#4968712)

Just compiling PHP scripts on every page hit.

Ok, lets see, in the same thread there is a post about PHP not having an XML parser of any kind (the author mentions having to use regexp, insane as that sounds), I am assuming that means there is no HTML parser (or an equivalent of HTML::TreeBuilder at that) either.

Call this "informative-flame" bait, but I am trying to figure out why people get upset when PHP isn't refered to as the greatest thing of all time. I personally haven't used it for a couple of years, so I don't know about many of these features.

What does PHP use in terms of a browser agent (a la LWP)? Is there really no support simple filebased db persistence? (by which I mean something along the lines of tieing a hash to BerkleyDB). How well does it hook into the other stages of the Apache request handling pipeline?

Oh and something I'm curious about (too lazy to look it up, I guess) what sort of exception handling does PHP have (ie it's equivalent of 'try {} catch {} finally {}')?

What sort of logging modules are available? (log4PHP?) I'd also be curious to know about how PHP's templating systems measure up, from someone who's had experience with this sort of thing...

Anyway, this is a troll, but I am curious about the answers to those.

Re:consider running an opcode cache (1)

FooManChuYouMoo (183196) | more than 11 years ago | (#4968778)

I use phpaccelerator. I do some moderately advanced things with php, and it works great. I've had no problems with it.

Still no non-experimental Apache2 support? WTF? (0, Interesting)

Anonymous Coward | more than 11 years ago | (#4968586)

Apache2 has been out for what, almost a year? And we still have no REAL support for Apache2 other than as a CGI? What is going on in the minds of the PHP developers? This is absolutely terrible.

Mandatory ISR joke: In Soviet Russia, PHP 4.3.0 launches YOU.

Most needed feature for newbies...... (2, Insightful)

ShatteredDream (636520) | more than 11 years ago | (#4968669)

Is better documentation. Like most CS students I got started with Java. The Javadocs are incredibly easy to read and learn Java from. The PHP docs are anything but easy to read by comparison. Thus far, the only PHP I've learned is from books and source code (it's pretty easy to pick out what most PHP functions do from source examples). Python suffers from a similar problem IMO. I've been trying to get started with a bit of XML parsing and tried Python first. It was a pain in the ass to figure out what classes were being returned by functions among other things.

I think OSS projects working on languages and libraries should commit to including comments like this to help newbies (especially if the language is dynamically typed) /*
function name:
input parameters:
return type:
purpose:
parameter 1: (purpose)
parameter 2: (purpose)
*/

Re:Most needed feature for newbies...... (0)

Anonymous Coward | more than 11 years ago | (#4968728)

PHP is WAY much better documented than Java. If you want to get something done, just go to the PHP site and read the documentation, search for keywords, you'll find it.
Whereas in Java you spend hour looking for a WORKING solution in the first place, then you have to hack in many many lines of code only to discover
a) it doesn't work
b) it won't work on another application server

So far I and almost everyone I know have been much more productive using PHP, producing more portable, stable applications faster than with Java.

I know, Java is much cleaner in design than PHP but in respect to productivity its right up there with ...well even VB might be better...

Re:Most needed feature for newbies...... (2)

glwtta (532858) | more than 11 years ago | (#4968822)

Well this is certainly a helpful reply:

Original Post: I read the Java and PHP docs, and java is better documented.
You: No, Javadoc sucks, go read the PHP docs. And java sucks too!

Correct me if I'm wrong, but PHP doesn't seem to have a "self documenting" framework, a la Javadoc or even Perl's POD?

Re:Most needed feature for newbies...... (0)

Anonymous Coward | more than 11 years ago | (#4968874)

Are you kidding?

IMHO, PHP's docs are one of, if not *the* biggest advantages of the language. And from what I've seen, my opinion is shared in the PHP developer community.

I don't even own *one single book* on PHP, and I've been coding in it for almost four years now, thanks to their great docs.

Do a search on /. for a review of a book on PHP. You'll probably see comments along the lines of, "Who needs a PHP book? I just use PHP's great documentation."

-chris

Re:Most needed feature for newbies...... (1)

ajayrockrock (110281) | more than 11 years ago | (#4968927)

The PHP manual is excellent, nothing new there. But you're right in that people who write PHP code suck at documentation. There are a couple of projects that are trying to make it easier though. I just found this [callowayprints.com] one that uses the the same javadoc program to document PHP classes. Kinda cool, IMO.

later,
ajay

Re:Most needed feature for newbies...... (1)

cshoes (459798) | more than 11 years ago | (#4969006)

I have to agree. Anytime a PHP book is reviewed, theres obligitory posts modded to 5 saying the web docs are enough to learn by. I must disagree. The function reference is nice (but your correct, Javadocs blows it out of the water). But for learning the ropes of the language, it does not do well. People learn by examples and tutorials, thats where the books fill the gap. I for one learned quite a bit from the PHP 4 Bible (too tired to find a link to it, but its fairly common).

whooooohoooo (0, Offtopic)

Urinol (579074) | more than 11 years ago | (#4968701)

now I can die happy :D

Now If ENSIM would Get Off Their asses... (2, Interesting)

tyrnight (633534) | more than 11 years ago | (#4968784)

This is fine and dandy and all.. but for all of us Ensim users.. we are still stuck on outdated PHP and apache.. Ensim still relies on their own versions oh PHP and Apache.. THIS SUX..

*now watch the flames from under me* hehe
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?