PHP 4.3.0 Released

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."

Comments

Nice

[HowlinMad]

I like the bundled GD library.

Re:Nice

[drightler]

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

That's great

[Karamchand]

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

[Anonymous Coward]

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

[MmmmAqua]

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

[rollthelosindice]

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

Re:That's great

[ajayrockrock]

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

Re:That's great

[yem]

Yes, this is a shame. I too hope they can get together and freeze the API or whatever it is thats holding things up.

Last time I tried php with apache (4.2.2 + 2.0.43 IIRC), apache would segfault when it received a SIGHUP after log rotation. It seems libphp4 was not handling the signal correctly.

This may have been solved by now, but I'm not going to use PHP with Apache 2.x until it gets better than this.

Re:That's great

[Anonymous Coward]

I've got the same with apache 1.3.x and php 4.2.1
Solved it by installing a service guardian (checkservice), but it's still very 'misc' and unpredictable.

And this is on a production machine, ouch :(

I'm waiting for php.NET

[Anonymous Coward]

when's that due?

Re:I'm waiting for php.NET

[neverkevin]

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

Re:I'm waiting for php.NET

[Karamchand]

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

[YellowSnow]

To eliminate duplicate Slashdot posts

Re:But does it have the Power

[whiteranger99x]

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

[anarchima]

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

Re:But does it have the Power

[Anonymous Coward]

I don't know. Does it have the ability to eliminate duplicate Slashdot posts?

Re:But does it have the Power

[YellowSnow]

Perl = Pesky editors repeat largely?

Shit.

[Dark Lord Seth]

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.

Re:Shit.

[Anonymous Coward]

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

PHP...

[Anonymous Coward]

almost object oriented.

Best New Feature

[The-Perl-CD-Bookshel]

Is the friendly error messages , they point you back to the PHP Documentation. 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

[netsharc]

Hehe, you say it right, PHP is nowadays too popular that every "I know Frontpage!" idiot has begun trying it.

Yes I'm an elitist. Leave computing to the real guys.

Re:Best New Feature

[The-Perl-CD-Bookshel]

My favorite are the Web Monkey'esque articles that show you how to create a content management system that can be "hacked" by an 11 year old with little more PHP knowledge than O'Reilly's pocket reference.

Re:Best New Feature

[Anonymous Coward]

Uh oh! It's become easy to use! All you "leet" folks are gonna have to move to a more obscure language to redraw that dividing line between you and the "n00bs".

There's nothing more pathetic than web "programmers" who think they're elite. You guys might as well take up basket weaving. It's at approximately the same technical level...

Re:Best New Feature

[Anonymous Coward]

Yes I'm an elitist. Leave computing to the real guys.

Sure. Let me know if you run across any.

Re:Best New Feature

[Anonymous Coward]

Yeah, there's nothing more annoying and pathetic than people trying to learn new things and grow. Good to see you're leading the example against this dangerous movement.

Re:Best New Feature

[netsharc]

I have nothing against learning and growing, what I hate are people who don't read the documentation and ask dumbass questions. Too bad I can't find any example, but if you read the PHP forums I'm sure you'll see a few of them.

Re:Best New Feature

[Anonymous Coward]

Sure, I hate that too, but that's not what you were saying. You were railing against people who are not "the real guys" (like yourself, presumably) now "trying" PHP. You were not lamenting that people don't RTFM, but that PHP has grown so popular that it upsets your elitist sensibilities.

But of course, no one becomes a "real guy" unless they experiment, try new things, and yes, ask a few dumbass questions here and there. If you went your whole computing career without annoying at least one person with a question they didn't feel like answering at the time, I'll eat my hat.

I hate people who don't read the docs as much as you do, but stick to one argument at a time.

PGSQL support problem?

[DragonMagic]

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?

[Anonymous Coward]

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

Re:Why I prefer PHP to Perl

[The-Perl-CD-Bookshel]

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

Re:Why I prefer PHP to Perl

[SweetAndSourJesus]

Haven't I heard this somewhere before?

built for the web?

[ufoo]

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?

[pig-wfa]

how else would you deliniate?

Re:built for the web?

[The-Perl-CD-Bookshel]

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?

[bdesham]

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?

[Anonymous Coward]

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?

[FireChipmunk]

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?

[rycamor]

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?

[Arethan]

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.

Re:built for the web?

[ufoo]

The echo command is documented with a function prototype that looks like this:

echo ( string arg1 [, string argn...])

don't the parentheses signify a string well enough? For instance, supposing one wants interpolation, why should one have to use

echo ("<a href=\"$foo\">$bar</a>");

or:

echo ('<a href="' . $foo . '">' . $bar . '</a>');

or:

echo <<<END
<a href="$foo">$bar</a>
END;

when

echo (<a href="$foo">$bar</a>);

is so much cleaner? Everything between the parentheses is clearly a string, and should be interpolated. Strings between parentheses should work like a heredoc. Using quotes to signify interpolation is a bad choice for a language built to make Web documents, which [should] use quotes for attribute values.

Right... need to be able to evaluate expressions...

echo ($foo * $bar);

Which do you use more when using echo -- string interpolation or expression evaluation?

I concede that the above is a pointless argument as really string interpolation like what you see above doesn't actually belong in a script. It should be in a template instead. I use PHP from time to time, and I don't find it difficult to use at all. But this is one thing that has always annoyed me.

Just my $0.02

Re:built for the web?

[Anonymous Coward]

hi, everyone,

been in a startup, watched difficulties getting perl do the job for the web site. The perl guy was an expert. However, php was x times more easy to allow services on our websites, permitting ease of interactivity, ease of personalisation to the final user. So finally, we moved to php.

Perl is to my little knowledge an outstanding language as many are. Anyway, php was designed for this and it does really well and really quickly the job from idea to production.

think of yahoo move from C/C++ Y++ to php ...

Re:built for the web?

[htmlboy]

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

so long as we're talking about being built for the web, shouldn't it be more like this?

echo "PHP is &quot;built for the web&quot;.";

Re:built for the web?

[Zontar The Mindless]

More like

echo "PHP is <q>built for the Web</q>";

Q element. :^)

Re:built for the web?

[Anonymous Coward]

Close... this is the correct use of "heredocs". Note the added "". Make sure there is absolutely no whitespace before or after the "END" and "END;" parts or you'll get errors...

echo END
"built for the web?"
END;

Re:built for the web?

[Zontar The Mindless]

You left a bit out. Try

echo <<<END
"built for the web?"
END;

instead.

See here, Doc. :)

Re:Why I prefer PHP to Perl

[drightler]

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

Dynamic extensions for MacOSX

[ravemax]

Finally dynamic loaded extensions are supported on MacOSX.

Re:Dynamic extensions for MacOSX

[Daniel Dvorkin]

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

[Daniel Dvorkin]

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.

In a related note....

[Davorama]

...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)

Yes!

[Anonymous Coward]

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

Re:Why I prefer PHP to Perl

[Anonymous Coward]

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

Apache 2.0 friendly

[josephgrossberg]

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

PHP and Apache 2.0 documentation

Re:wow

[Dark Lord Seth]

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:Command Line Interface?

[Mitchell Mebane]

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

Re:Why I prefer PHP to Perl

[jmertic]

* 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?

XML?

[King of the World]

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?

[DragonMagic]

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?

[Randolpho]

You should consider switching to the Zope 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?

[FamedLamer]

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

Agenda pushing?

Re:XML?

[King of the World]

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?

[King of the World]

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?

[Anonymous Coward]

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?

[HarrisonFisk]

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

There also is a nice wrapper called XML_parser 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

I see nothing lacking with PHPs XML support.

Re:XML?

[King of the World]

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?

Re:XML?

[HarrisonFisk]

Maybe I phrased that wrong.
The EXPAT parser has come standard built into PHP since 4.0 beta 3. You have to willingly disable it at compile time with the --disable-xml flag.

The XML PHP library again will be installed automagically as part of the base PEAR install, unless you say otherwise.

The only thing you are required to install from my above post was the XML_RSS library, everything else comes STANDARD with PHP unless you compile without them.

Re:XML?

[Anonymous Coward]

lets face it, OO in PHP isn't great, and that's what most people have been waiting on

OO is a fad. It will die out soon. OO is for people who don't get "true" relational-functional modeling. Read Chris Date's material.

Re:XML?

[chregu]

4.3 was never supposed to be the "OO-Release". Better OO-Support will come with Zend Engine 2, which will be most certainly be in PHP 5.0. You can't expect a stable release of that until next summer.

chregu

Re:XML?

[rycamor]

>>OO in PHP isn't great, and that's what most people have been waiting on PHP 4.3 to fix

No, that's what people have been waiting on PHP 5 with Zend 2.0 to fix. Big difference.

However, your comments about XML and string handling have nothing to do with PHP's OO capabilities. I would argue that PHP's string handling and regex are better than the standard ones you find in Java or .NET.

XML support? Well, yes PHP isn't a native XML-handling language, nor is Java (.NET might be another story).

With any standard programming language, though, XML support is not "native". You have to include the appropriate modules or classes. Ditto with Java.

Re:XML?

[chregu]

Almost anything is optional in PHP... MySQL and expat (= XML SAX support) are just enabled by default, but you can disable them easily within configure. But neither Postgres nor db2 are enabled by default.

Other XML-Features (DOM-Support, XSLT, XMLRPC) can also be easily added within the configure script. But it's true, it needs a recompile then (at least for these extension, if they are loaded dynamically later..)

chregu

Re:XML?

[sqrlbait5]

We've been using the latest CVS of PHP and have been enjoing the DOM XML, which is in 4.3 final. Check it out at http://www.php.net/manual/en/ref.domxml.php . It's pretty straight forward and offers all the XML functionality you could want.

Re:XML?

[King of the World]

Thanks!

Re:XML?

[Malcontent]

please educate yourself further. When you post obviously ignorant remarks like this you make yourself look extremely dumb.

You can compile SAX or DOMXML function into php or you can load them as modules. Same with mysql and postgres. As a rule PHP can load any set of functions dynamically or it can compile them statically.

Having external libraries is no different then PERL having modules, or VB having dlls, or java loading classes.

All the libraries you need are included in the distribution. Get the source code and do a ./configure and choose the modules you want loaded statically. What is this nonsense you are sprouting off about them not "being included by default".

Please do yourself a favor and actually install the thing before you start rambling about things you know nothing about.

Re:XML?

[Malcontent]

Please go to sourceforge and type the following words into the search engine.
php apache windows install

Make sure you have "must contain all words" checked. There you will find some installers which will set it up for you with no problems.

Re:XML?

[King of the World]

Look you obnoxious boy, when did I ever say it wasn't possible? Where did I ever say that the issue I have with PHP was to do with lack of support for XML?

I didn't. You're an obnoxious git who argues against cliches of his own invention.

However, I did say "there's no way in the standard PHP build to deal with XML" because in 90% of the installed PHP base out there there is no XML support. As AC said,

"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"

The PHP programmers obviously recognise the distinction between being included in the standard build and being an optional extra. You insult me for making the same distinction. Not including it by default means it won't be available on 90% of the installed PHP hosts out there, meaning that those offering (OSS) PHP software for download can't rely on others having those libraries. Notice the distinction?

I'm not saying include everything by default - as I'm sure you'll extrapolate my point to. I am saying that XML support should be default, like GD.

You can't even talk respectfully to strangers. You're a freak.

Re:XML?

[Anonymous Coward]

"You're an obnoxious git who argues against cliches of his own invention"

Wow, you just nailed half of the slashdot crowd!

"You can't even talk respectfully to strangers. You're a freak." ...And that covers the other half, hahaha!

Re:XML?

[Zontar The Mindless]

> I see nothing lacking with PHPs XML support.

Expat/SAX in PHP rocks. XSLT is pretty good. The PEAR XML parser isn't bad, either.

However, XML-DOM (DOMXML, whatever) sucks because, well, can you say, "Shifting APIs"? On the one hand, I appreciate the fact that it's getting fairly close to W3 specs now, and that's a Very Good Thing(tm); on the other, the function names and definitions (along with some of the interfaces themselves) have changed in very non-trivial ways with nearly every single bloody point release since 4.0.0 and it's a royal pain in the arse. I'm working on a project right now that would be much better done if we could depend on consistent DOM support.

My pet peeve aside, the new release looks pretty good. :)

(Before you flame, please consider the possibility that there might be other uses for the Document Object Model besides making stuff fly around in browser windows. Thank you.)

Re:XML?

[Malcontent]

"The PHP programmers obviously recognise the distinction between being included in the standard build and being an optional extra."

Once again go and actually install the thing before you make ignorant comments like this. You have to configure the thing before you make and install it. Have you ever compiled a unix app before? Who the hell cares what is "default" and what is not. You always have to include at least one thing or another or you are going to get a pretty useless php build.

If you are really too stupid and lazy use the debian system. They have separately compiled each and every php option into loadable modules so you can do things like apt-get install php-XML. Or you can use freebsd which gives you the popular options in a menu.

Moron.

Re:XML?

[King of the World]

Who the hell cares what is "default" and what is not.

PHP programmers, me, and apparently a few others.

What is default will spread more than what is optional. Recognising this has allowed programmers to rely on features.

You always have to include at least one thing or another or you are going to get a pretty useless php build.

By default PHP is "pretty useless". Heh.

Nobody is the same, but if 50% of people are compiling in GD support then it should be included to save them the effort. Making defaults suit the most people is a great thing.

When did I ever say that I had not installed it? When did I ever say that the issue was with running the software I want on my system alone?

Again, you seem unable to distinguish between your own cliches and my posts - between your imagination and reality.

And you have the gall to call me a moron. Seek help, buddy.

Re:XML?

[Malcontent]

" Who the hell cares what is "default" and what is not.

PHP programmers, me, and apparently a few others."

Man you keep bitching about this. Let me get this straight now. You are bitching and moaning about the fact that you have to type --with-xml when you build it. Is that right? Here let me quote your original post to let the world know exactly how stupid you are.

" 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)."

So because you are too dumb to know to type --with-xml and because you are too lazy to actually read the manual and because you are too blind, high and retarded to follow the instructions when you type ./configure you have to actually write XML parsers using the built in regular expression functions.

Yes that's exactly what you said!. Hey people look at me I am too stupid to type --with-xml so I bitch and moan about parsing XML with regular expressions.

MORON.

Re:XML?

[King of the World]

Man you keep bitching about this. Let me get this straight now. You are bitching and moaning about the fact that you have to type --with-xml when you build it. Is that right?

No. No. No. Read. Comprehend. Post. And I must say how very unlike you it is of you not to read my posts and for you to invent my argument as you go.

Maybe if I repost what I've already said again and again you'll read it. Then again, maybe you're insane...

"What is default will spread more than what is optional. Recognising this has allowed programmers to rely on features."

"...in 90% of the installed PHP base out there there is no XML support"

If I offer PHP software for download then in practice more people will use it and be able to use it (ie. generic php hosts) if I use default features. With your take on it I shouldn't consider what's default and what's not. Your ignorance in saying "Who the hell cares what is 'default' and what is not" states that defaults don't matter. When Redhat includes GLIBC by default, years ago, programmers could finally use it. It's not a problem downloading and configuring software on my box, it's the social situation of releasing software. Your beliefs go against PHP's programmers who decide what should be included by default.

You continue your rude, arrogant, and angry posturing. There won't be any posts responding to you, freak.

Re:XML?

[_Donut_Troll]

Man you keep bitching about this. Let me get this straight now. You are bitching and moaning about the fact that you have to type --with-xml when you build it. ... So because you are too dumb to know to type --with-xml and because you are too lazy to actually read the manual and because you are too blind, high and retarded to follow the instructions when you type ./configure you have to actually write XML parsers using the built in regular expression functions.

You've managed very well to miss the point by a country kilometer, O Clueless One. Let me lay it out before you in nice simple Sesame-Street lettering, so you don't miss anything:

Out in that magical, mystical wonderland known as "The Real World", there are a lot of PHP developers out there who
DO.
NOT.
HAVE.
ADMINISTRATIVE.
ACCESS.
TO.
T HE.
SERVERS.
THAT
THEIR.
SITES.
ARE.
HOSTED.
ON.

This means that they CAN'T upgrade or augment PHP whenever they feel like it. This doesn't mean they're ignorant or lazy.

How often have you been able to get your typical hosting service to drop everything in order to recompile PHP just so little ol' you can have that cool extension you'd really like to be able to use on your site? Or letting you do it? ("Sure, laddie, here's the root password to my employer's server -- recompile and reconfigure to your heart's content." Not bloody likely.) Most commercial hosts use the standard distribution of whatever, and that's that. If you want a feature that's not included by default, you're SOL.

This is exctly why MySQL and Postgres (and now GD) were included in the default build. So that people developing PHP-based sites on servers that they don't own weren't deprived of these useful features by the incompetence, impatience or laziness of those who do control them. (Or that of their PHBs.)

You, sir, are a short-sighted, loud-mouthed, thoughtless, elitist fucktard.

Re:XML?

[Malcontent]

"When Redhat includes GLIBC by default, years ago, programmers could finally use it. It's not a problem downloading and configuring software on my box, it's the social situation of releasing software. Your beliefs go against PHP's programmers who decide what should be included by default."

Oh come on now that's a ridiculus argument to make. If you are delivering your application to somebody make the xml module a .dso and have them load it. It's like delivering any other software, if your software a library dependencies then you either ship the library or ask them to download and install it themselves.

Re:XML?

[Malcontent]

People who do not have root access to their machines can not install the vast majority of the software available to them. Why is this any different?

If your php host does not have the XML module installed then find somebody else. What if you wanted the CURL extension or the ming extensions and your provider did not install them? Should those be in the default too? How about the ovrimos database functions let's roll them up as default too who knows somebody might want to write an application using them. Yes roll up everything anybody might want to use and deliver a bloated slow php to everybody.

Oh and by the way you do not have to recompile php to load modules. You can load them dynamically. If your host is not willing to put in the function you want either by compiling or loading dynamically then by all means drop them like a rock and find a host that is more responsive to your needs. Why would you want to host your website with somebody who was "incompetent, impatient, and lazy" anyway?

Re:XML?

[Anonymous Coward]

May you never run a company.

Re:XML?

[Anonymous Coward]

"How about the ovrimos database functions let's roll them up as default too who knows somebody might want to write an application using them. Yes roll up everything anybody might want to use and deliver a bloated slow php to everybody."

He-he! He said you'd you would extrapolate it to including everything by default! you're a fucking moron!

Re:XML?

[Zontar The Mindless]

> Why would you want to host your website with somebody who was "incompetent, impatient, and lazy" anyway?

Well, _Donut_Troll was wrong about both PG and needing to recompile, but he's right in that there are all kinds of situations where a developer might not have control over the server itself. That could be determined by an employer or client -- or the hosting might be locked in by a long-term contract. The poor schlob's supposed to drop his job or the equivalent just to satisfy your worldview? Geeez.

(Another scenario: The developer's obligated to work on IIS, which IIRC doesn't support dl() in ISAPI mode.)

Why do you persist in being such a hard case, anyway? If you don't use MySQL or GD or whatever, that's fine, it's not like somebody's forcing you to, so if it's helpful to (some) other PHP developers, how does this hurt you? Do you also oppose the inclusion of PEAR by default, which most would probably agree is a good thing?

Re:XML?

[Malcontent]

And if I do may I never ever have stupid, lazy whining people as employees.

Re:XML?

[Malcontent]

DOnut troll was wrong about a bunch of things but we'll let that go for now.

"but he's right in that there are all kinds of situations where a developer might not have control over the server itself. That could be determined by an employer or client -- or the hosting might be locked in by a long-term contract. The poor schlob's supposed to drop his job or the equivalent just to satisfy your worldview? Geeez."

There are some people with no control over their programming environment. Boo Hoo. I don't want my php bloated to satisfy the needs of the minority.

Re:XML?

[Anonymous Coward]

PERL sucks ass. Too much nonsense for simple functions. PHP, like ASP is flexible and faster than PERL.

Why don't you get with the times?

uh

[SweetAndSourJesus]

The command line interface 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?

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

never mind

[josephgrossberg]

oops ... if this post is accurate, it appears I misunderstood.

Re:never mind

[Karamchand]

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.

Re:Why I prefer PHP to Perl

[Anonymous Coward]

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.

silly (probably) question

[glwtta]

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

[pig-wfa]

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

Re:silly (probably) question

[DragonMagic]

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.

Re:PHP and GD

[RetroGeek]

And this from an AC ....

Just an Observation

[Anonymous Coward]

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

[happypizzaguy]

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

Re:Command Line Interface?

[akac]

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:Why I prefer PHP to Perl

[glwtta]

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.

consider running an opcode cache

[Kunta Kinte]

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

[drightler]

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

Re:consider running an opcode cache

[MmmmAqua]

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 (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

[glwtta]

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

[Anonymous Coward]

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

[FooManChuYouMoo]

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

Re:consider running an opcode cache

[Second_Derivative]

Anyone have any experience with APC?

Re:consider running an opcode cache

[Kunta Kinte]

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

[Anonymous Coward]

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.

There's no treebuilder or concept of nodes or anything like that in PHP. They're still thinking in flat structures.

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.

Oh it's mediocre, as I soon found out :(

What does PHP use in terms of a browser agent (a la LWP)?

None. They've had a long time to do something.

Is there really no support simple filebased db persistence? (by which I mean something along the lines of tieing a hash to BerkleyDB)

It doesn't.

How well does it hook into the other stages of the Apache request handling pipeline?

It doesn't.

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?

Well it has that. It doesn't have /manual/en/ref.errorfunc.php (in summary, it blows)

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...

Well templating is quite well done. There's FastTemplate and Pear's one. It's difficult to do XHTML templates without XML support. I guess it's not easy.

Re:consider running an opcode cache

[Anonymous Coward]

Not an entire solution, but see the FREE (take that Zend! ;) PHP Accelerator.

VERY easy to install and works VERY well! :)

Re:consider running an opcode cache

[MmmmAqua]

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.

The problem with this idea is that it's neither practical or smart to build a partial opcode cache. In a vanilla install, a PHP script goes through three stages: interpretation, compilation, and execution.

The script is first read, parsed for correct syntax and validity. It is then translated to a bytecode format that the Zend engine understands, and executed. The main thing the Zend Performance Suite does is to make the bytecode persistent, so the expensive interpretation phase happens only once per script.

So, given this simple process, how do you make a partial opcode cache? Only make every other script that is run persistent? Only make certain parts of the script persistent? It's pretty much an all-or-nothing thing. You could say that a partial opcode cache would not perform the optimizations that Zend's product does, but that doesn't work either - Zend already gives away the Zend Optimizer for free (which itself is a great product for speeding up your overall PHP performance).

I don't have the answer to this question, but considering that neither do Zend or the PHP team, there must be something to my reasoning.

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

I disagree completely. Variable variables, regex, and disk I/O are important features to leave out. PHP is a *language*. Do you bug IBM's javac team, or the Blackdown project because Java doesn't support covariant return typing? No. Why not? Because that's a language feature, and those guys deal with the runtime. Conversely if you want something that's a runtime issue (such as persistent bytecode), then you talk to the guys who are responsible for the runtime. The PHP developers are responsible for developing PHP as a language, and the API which supports it. They're not responsible for the runtime, Zend is.

Re:consider running an opcode cache

[Pr0xY]

I don't know about php, but i do know the same concept goes by many different names (depends on what community you are talking with). For example, in emulation the same concept is called "Dynamic Recompilation", it sounds fancier but it's the same thing. I am sure that they must have some sort of cache system to reduce the amount of interpretation they do (they could do a lot of "High Level Emulation" with objects simply by representing them as real objects in the source language, etc, etc). PHP is damned fast for everythign i've thrown at it.

Just may not have same name as you are used to referring to it by...then again, there is always room for improvments ;)

proxy

Re:consider running an opcode cache

[rycamor]

>> What does PHP use in terms of a browser agent (a la LWP)?

>None. They've had a long time to do something.

Umm... http://php.net/curl (this is only one of several methods you can use)

>There's no treebuilder or concept of nodes or anything like that in PHP. They're still thinking in flat structures.

http://php.net/dom-xml (admittedly experimental, but it's been around for almost 3 years)

>> Is there really no support simple filebased db persistence? (by which I mean something along the lines of tieing a hash to BerkleyDB)

>It doesn't.

BerkelyDB? Who uses that thing anymore? :-) (http://www.php.net/manual/en/ref.dba.php)

>>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?

>Well it has that. It doesn't have /manual/en/ref.errorfunc.php [php.net] (in summary, it blows)

PHP5 will have try/catch/finally. Yes, these days it still blows.

>>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...

>Well templating is quite well done. There's FastTemplate and Pear's one. It's difficult to do XHTML templates without XML support. I guess it's not easy.

There are quite a few good templating engines with PHP, including two which are PHP modules (compiled C code), providing good performance.

Re:consider running an opcode cache

[nkg]

Don't wish to sound like a troll and by your other helpfull responses i presume you are not trolling. But how is it difficult to do xhtml in templates?


ie xhtml Transitional header.tpl

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transition al.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>

<title>{$title}</title>

<link rel="StyleSheet" href="{$screenCss}" type="text/css" media="screen" />
<link rel="stylesheet" type="text/css" media="print" href="{$printCss}" />

<script language="JavaScript" type="text/javascript" src="functions.js"></script>

<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />
<meta http-equiv="pragma" content="no-cache" />
</head>
<br />

ie html Transitional header.tpl

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<title>{$title}</title>

<link rel="StyleSheet" href="{$screenCss}" type="text/css" media="screen">
<link rel="stylesheet" type="text/css" media="print" href="{$printCss}">

<script language="JavaScript" type="text/javascript" src="functions.js"></script>

<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<meta http-equiv="pragma" content="no-cache">
</head>
<br>

oh if inteested my template engine of choice is Smarty http://smarty.php.net

Re:consider running an opcode cache

[Malcontent]

"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.'

PHP has both SAX and DOM based XML parsers. It also has an xmltree function to instantly build you an object hierarchy from an XML document. There is also the most excellent phpxpath object available here

"What does PHP use in terms of a browser agent (a la LWP)?"

It supports fetching from URLs the same way as opening and fetching from files. The new version also has streams. Also it has hooks into CURL for more sophisticated stuff. There is also the excellent snoopy object.

"Is there really no support simple filebased db persistence? (by which I mean something along the lines of tieing a hash to BerkleyDB)"

There are hooks into berkley db if you want to sink to that level. If you want to sink even lower then any php variable, array or object can be turned into a string and saved to files or sent to other URLs or what have you.

"How well does it hook into the other stages of the Apache request handling pipeline?"

You don't have that much control over the pipeline but you can hook into auth and such. I never needed anything it did not provide.

"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 {}')?"

PEAR has a pretty good error handling library. Otherwise you basically just test for errors manually. You call a function with @function which surpresses error messages but sets global error indicators which you can test for. Not great but gets the job done. Version five will have try catch. All in all error handling in php is better then perl and worse then java.

"What sort of logging modules are available? (log4PHP?)"

PEAR has a logging class. I know that there are others out there as well. PHP also hooks into syslog if you want that.

" 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..."

smarty is an outstanding templating engine with caching. I don't see how you could possibly do better. There are numerous others.

I hope this prevents you from further trolling. Now that you are armed with actual knowledge (which you could have gotten by simple searching) you no longer need to troll here.

Re:consider running an opcode cache

[glwtta]

Thank you, very informative. And why would I want to search for all this myself when I could just ask knowledgeable people and quickly get a summary of all I wanted to know? :)

All in all error handling in php is better then perl and worse then java.

This I find hard to believe, the only advantage java has over perl in this regard is checked exceptions (and certainly enough arguing has taken place over whether or not this is actually a good thing). So PHP adds a feature over and above perl's Error.pm which insn't quite as good as checked exceptions but enought to make it better?

Anyway, thanks for the answers, this was a very useful troll.

Re:consider running an opcode cache

[Dragonshed]

apt-get install php4-apc, or download from here.

Re:consider running an opcode cache

[Anonymous Coward]

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

Hmm...

Linux... $0
Apache... $0
PHP... $0
Zend Performance Suite... $1875

Windows 2000 Server... $900
ASP.NET... $0

I guess maybe you're right. :)

Re:consider running an opcode cache

[Malcontent]

"So PHP adds a feature over and above perl's Error.pm which insn't quite as good as checked exceptions but enought to make it better?"

It's not just that. There is a lot to php error handling. You just have to learn about it and use it to your advantage. I personally think try catch is not that great and in some ways would prefer the existing php error system. A stack trace would be cool thought.

Re:consider running an opcode cache

[Anonymous Coward]

Never got that thing to compyle... and the precompyled (yuck!) binaries don't work with php >4.1

Re:consider running an opcode cache

[rycamor]

>But how is it difficult to do xhtml in templates?

That wasn't me saying that. I was responding to the original poster. You are correct; XHTML is completely a client-side thing, so it has nothing to do with PHP support.

By the way, there is a cool PHP class that dynamically generates well-formed, indented XHTML: phpHTMLlib.

Re:consider running an opcode cache

[Anonymous Coward]

If you want to sink even lower then any php variable, array or object can be turned into a string and saved to files or sent to other URLs or what have you.

Except that when you un-serialize an object of a class which has methods, those methods are gone. Kinda defeats the purpose when you're doing anything more than dead simple.

Re:consider running an opcode cache

[nkg]

aye. sorry about that. in tiedness didn't notice.

Thanks for the link.

Still no non-experimental Apache2 support? WTF?

[Anonymous Coward]

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.

Re:Command Line Interface?

[soundofthemoon]

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!

Re:Why I prefer PHP to Perl

[mstyne]

Good lord, go outside.

SHUT THE FUCK UP, MORON

[Anonymous Coward]

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

Re:SHUT THE FUCK UP, MORON

[Anonymous Coward]

That's right. Chicks only dig nice slashdot trolls. Lose the condescending attitude, though, and you're in blowjob heaven.

Re:SHUT THE FUCK UP, MORON

[Ponty]

I kind of dig it. You see, you've fallen into the trap that he was suggesting that the original poster try harder to perfect. Bing!

Re:Why I prefer PHP to Perl

[Christianfreak]

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 or maybe the GD library (which is what PHP uses). Oh yeah there's even a Gimp Perl interface. Not to mention SDL tie in and several others. In fact if you go to CPAN Search 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 nothing PHP has even comes close to the amount of add-ons and extras that are easy to find and just work.

Most needed feature for newbies......

[ShatteredDream]

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......

[Anonymous Coward]

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......

[glwtta]

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......

[Anonymous Coward]

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......

[ajayrockrock]

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 one that uses the the same javadoc program to document PHP classes. Kinda cool, IMO.

later,
ajay

Re:Most needed feature for newbies......

[cshoes]

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).

Re:Most needed feature for newbies......

[caluml]

I can't believe you're saying this.
The PHP docs are brilliant.
You just type in the function name, and there are enough examples to get you running until you actually start understanding the language.

I learnt PHP purely from www.uk.php.net, and I have always found the Java and Perl docs to have too much stuff in them.

The PHP docs are like this:
mysql_connect ([hostname],[username],[password]) Returns true if successful.
What more do you need to know? What goes into a function, what comes out.

I'm genuinely not trolling here, I'm just surprised that anyone could moan about the PHP docs.

Re:Most needed feature for newbies......

[gheidorn]

PHP is WAY much better documented than Java.

False. Both are documented appropriately. Java API is structured for your reference, allowing you to create your own implementation. It will not show you the way, but merely provide you with the plumbing. PHP's manual does the same thing. You bias may stem from the fact that not only does it accurately decsribe the functions, but it allows for users to add their comments on how best to use it. A similarly moderated version of this would behoove Java. I love both languages. PHP for quick applications, Java for enterprise applications.

Re:Most needed feature for newbies......

[compwiz]

That's like saying GTK+ docs are better than PHP docs just because you're used to the format. PHP has some really great documentation with useful examples, and very easy to learn with just the included API docs without even reading the 5-page tutorial. Instead of sheltering you with an abundance of "Hello World" examples, you can start producing real-world pages with PHP minutes after beginning to read some the documentation. That's a lot more than I can say for Java.

Re:Most needed feature for newbies......

[colinramsay]

I agree. The php.net references are excellent, especially when you add in the user comments that go with each function. In my limited experience with Java, the Sun docs are overly complex and have few practical examples. I'm sure there are better resources however. The point is that the most obvious PHP resource is excellent; the most bvious Java resource is not.

Re:Most needed feature for newbies......

[aint]

This is on the TODO but all the information is included on every man page currently. New parameters and changes to parameters are in the form of notes on each given doc page. So all the information you ask for is already available, just not in a consistant form. Yet. This is a big job, would you like to help? :)

Re:Most needed feature for newbies......

[aint]

And for people unable to read a prototype yet, this too is documented here:

How to read a function definition (prototype)

Re:Most needed feature for newbies......

[gid]

Well the online docs seem to be written for someone with a programming background. If you have no idea how a if, for, while, switch, etc control structures work, you might have a hard time. I've learned php from the web docs, and a few random examples and now I'm a wiz. It also helps when programming php to know how the web works since writing a php program is nothing how you'd write a c program. Once you get in this mode of thinking it all becomes very easy.

I never, ever wanted anything more than the existing web docs, but I came from a solid c/c++ background, and I already had been using html for 3 years.

Maybe it would help if there was a web primer to bring people up to speed where the function listing help would be of more using and make much more sense.

Re:Most needed feature for newbies......

[Zontar The Mindless]

The docs work pretty well for me.

Tip: To get the most out of the documentation, you really need to use the online version. You can query it quite easily from your browser simply by typing php.net/ThingYouWantToKnowAbout into your location window. It'll pull up a function name, list of function names that closely match your search term, or a list of pages containing the search term. Try something like php.net/integers (returns a list of 52 documents, most of which relate to integers in one way or another) or php.net/file (returns the manual page for the file() function) and you'll see what I mean. Also check the user-contributed notes. I've found a lot of good tips and hacks in those.

Re:Most needed feature for newbies......

[Greedo]

You're wrong. :)

Re:Most needed feature for newbies......

[snowrichard]

I have only been using PHP for about a year now, and have developed 2 web sites. I found it easy compared to Java, a lot faster to use and easier to debug than C, and using it to write web applications is very easy. The Mysql or other database support is easy to understand. And it runs on very low cost Linux web hosts.

I think I have learned enough to write an introductory tutorial now. Check it out on my site if you like. I have not completed the underlying program that I am using for an example yet so it is very rough. I need some people to critique the tutorial.

Re:Why I prefer PHP to Perl

[slamb]

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 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 and windowing libraries.

* 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.

whooooohoooo

[Urinol]

now I can die happy :D

Re:Why I prefer PHP to Perl

[Anonymous Coward]

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

[keiferb]

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

Re:Why I prefer PHP to Perl

[InfiniteWisdom]

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

I think they're being Slashdotted.

Now If ENSIM would Get Off Their asses...

[tyrnight]

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

Re:Now If ENSIM would Get Off Their asses...

[cybrthng]

You just need to get off your butt :)

http://forum.rackshack.net/showthread.php?s=&thr ea did=15611

already done! (ofcourse, not by ensim, but this dude puts out lots of quality fixes/updates as simple as rpm -Uvh file.rpm)

Re:Now If ENSIM would Get Off Their asses...

[lyonchik]

Apache - yes, but PHP on ENSIM is upgraded in 20 minutes... no problem incurred... check out the RackShack forums for example on how to upgrade PHP on an ENSIM box...

Re:Now If ENSIM would Get Off Their asses...

[tyrnight]

Yes.. Rack shack has Tremendous Ensim Admin help. thanks to several hero's in the forum.. :) I just wanted to light a fire under ensim.. hehe

Re:PGSQL support problem? OT

[lor3]

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.

Re:Why I prefer PHP to Perl

[Anonymous Coward]

non, we get paid more ;)

Re:Why I prefer PHP to Perl

[esconsult1]

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.

If that's all you think of PHP then you've a lot to learn jack.
First... almost no professional web programmer puts HTML in their code anymore (PHP or Perl), we tend to use OOP based templating systems. Makes it much easier to separate content and code in non trivial web applications.

Second... OOP makes it tons easier to write, again, non-trivial apps and libraries.

If all you're doing with PHP (or Perl) is to query a db and write the stuff to the screen, then fine, never use OOP or templates, but for large apps where many interface designers, multiple programmers and PHB's are involved, OOP and templates (be they Perl or PHP) are worth their weight in gold.

I think it's time that we stop saying that "PHP is just a web application scripting language" any more, it has matured quickly into a world class capable language. Why, just a months ago I wrote a PHP daemon, that uses sockets, forking and database connectivity. Up to 1.5 years ago, I would have automatically reached for Perl.

PHP has come very far, and at this juncture, is just as powerful as Perl both on the web -- and on the command line -- with all the new features in the just announced version. Plus, there's the added benefit of you not having to be a slave to CPAN for the tiniest bit of additional functionality.

Features

[chiller2]

I'd been waiting on the 4.3.0 release for some time as I really wanted gd 2.x support without the patching / using non-production releases of PHP. The image resampling function is so much nicer than the resize for generating thumbnail images on shopping / photo based sites, and now I can rewrite code to use it instead of spawning NetPBM. Good work PHP team!

Re:Features

[compwiz]

GD 2.x support has been in production PHP since 4.0.6. They just bundle it with the distribution now because upstream isn't really maintained anymore.

IN SOVIET RUSSIA

[evil_pb]

PHP releases YOU!!

Re:IN SOVIET RUSSIA

[lyonchik]

What Soviet Russia, man? No Soviet Russias any more!

Re:Command Line Interface?

[Anonymous Coward]

It's also useful for backend processing for database-driven websites that run entirely on PHP/MySQL. We use PHP shell scripts set on cron jobs to do some daily/monthly maintenance on the databases. What makes this really cool is that we can include the PHP files the sites actually use so we can make use of some of the more complicated functions implemented in them (for stuff like calculations etc) without having to rewrite them all over again.

Re:Why I prefer PHP to Perl

[Christianfreak]

First... almost no professional web programmer puts HTML in their code anymore (PHP or Perl), we tend to use OOP based templating systems. Makes it much easier to separate content and code in non trivial web applications.

Yes and being a proffesional developer I do that. For me its a lot easier to do in Perl than it is in PHP. Granted I haven't used PHP as long as I have Perl, so its a matter of personal preference.

Second... OOP makes it tons easier to write, again, non-trivial apps and libraries. snip ...

Plus, there's the added benefit of you not having to be a slave to CPAN for the tiniest bit of additional functionality.

Most of CPAN is reusable OO code so your statement is a contridiction. Perl includes many modules in its default install and its easy to add them. That doesn't make one a slave, it allows one to build programs that has only the things they need in them. If my program doesn't need a graphic interface or a mysql backend why should it be in my namespace at all??? With PHP there isn't anyway to take that out.

Finally I'm not trying to start a "my language is better war" my post was intended to refute untrue claims by a troll. Statements that Perl has no graphics interface or bad database interfaces just aren't true. The fact that they aren't in the core language doesn't make a difference, they are still availible if needed, and many people including myself feel that is a better way to do things.

If you like PHP that's fine. I like Perl and i"m sticking with it.

Other important fixes

[NastyGnat]

This release of PHP also fixes a wordwrap overflow that was found on 10 December.

This is one of the great things about opensource. The BugTraq announcement that just landed in my inbox shows the hole was found on the 10th, fixed on the 12th, and all of this released on the 27th.
MS would have been lucky to have just the patch out by the 27th...

Re:Other important fixes

[Anonymous Coward]

How is that so different then? If the PHP release and the Word patch were to come out at the same time?

What's that you say? The PHP fix was in CVS, so that's better? Let me go slap that on my production machine right away.

Note that your point would have been better juxtaposed if you said the Word release wouldn't come out until 2007 or something equally absurd.

Re:Why I prefer PHP to Perl

[Anonymous Coward]

The template-post of all template-posts! My lord, you have vouchsaf'd to me! I beg you, lord, furnish hitherto, that I migh smite the blogs of mine enemies.....

Why use the bundled GD libraries?

[fo0bar]

From the announcement:

GD library is now bundled with the distribution and it is recommended to always use the bundled version

Why recommend the use of their bundled library? Why is this any different from their MySQL support (IE, a "mini" bundled MySQL library is included, but can (and should be) overridden by the normal MySQL libraries if they exist on the system). I can understand that many machines don't have GD libraries, but why "recommend" that their own code be used as opposed to the system libraries if available?

Re:Why use the bundled GD libraries?

[compwiz]

Their MySQL libraries are included because it's one less system library to mess up detection of (there were a lot of newbies coming in with with "MySQL support is broken," etc. when their libraries were just out of whack.
GD is somewhat of a different story - it is the full version of the library, with fixes. The GD 2.x series suffered from a lack of maintenance, and now when it's being updated frequently, upstream changed the API which breaks PHP after GD version 2.0.8. Including GD means they get a lot less broken compilation reports, and can easily fix bugs found in PHP as they show up. It can still use the system library if available, like the MySQL libs.

Don't rush to install it on production servers

[compwiz]

As with all PHP .0 releases, be wary about installing this release on production servers, even though this release has gone through a lot more testing than usual. I know of at least a few annoying bugs which were not fixed before the 4.3.0 release, such as a memory leak in a string handling function, and the fact that all PHP error messages are output to the global Apache error log even if they're only supposed to be displayed on the page itself.
Also, I noticed that if you have older PHP3 classes lying around which mistakenly redeclare a function, the entire script which uses the class will now fail under 4.3.0, where it would not trigger an error under previous versions. This is not a bug, but beware of it since it could break older applications.

Re:Don't rush to install it on production servers

[Anonymous Coward]

err, the memory leak in the string functions was fixed before the release (I know, I fixed it!)

As for php version 3, well, yes, you need to port your applications between major versions of the language (most likely), test beforehand, and you should be fine.

Re:Don't rush to install it on production servers

[compwiz]

there must have been more than one memory leak then (not surprising), since the one I reported was only fixed in CVS.

IN SOVIET RUSSIA

[Anonymous Coward]

In Soviet Russia perl tells Andrew Tanenbaum he is obsolete!

Re:Why I prefer PHP to Perl

[Slur]

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)

Some correXions for you: PHP runs on about as many Unices as Perl, including Mac OS X. Perl 5 has been included with Mac OS X from its inception.

Re:Anyone have any experience with APC?

[brion]

We used it for a while on Wikipedia. Seemed to help, but you had to manually clear the cache files when changing the .php sources (with the mmap'd version, supposedly it can automagically check in shared-memory mode).

Also had some problems with it reporting segfaults sometimes when running scripts that used the same includes in a different order; this may be fixed in later revisions.

Some more corrections 4 U

[Slur]

PHP's braindead way of putting everything_in_the_same_namespace() gets really old.

Actually PHP has a few different namespaces. There's the global namespace, of course. There's the function-local namespace. There's an object-local namespace. The various global arrays, such as $_REQUEST and $_SERVER can be treated as their own namespaces in a manner of speaking.

Perl has references which can point to sub routines, arrays hashes or other contants or scalars.

PHP also has references, as in $myRef =& $myObject; or $myRef =& $myVar;. You can refer to functions by name and call functions through a variable, as in $val = $myFunctionRef();. PHP's unified method of handling arrays, scalars, hashes, and references is pretty nice IMHO, whereas perl's funky way of referring to members of hashes/arrays as scalars versus the hashes/arrays themselves with % @ designators is fairly pointless and the source of many bugs.

When they fix interpolation which is a nightmare

Silly rabbit. Interpolation in PHP is very simple and it just works:
print "Interpolate $thevar";
print "Interpolate $thearr[itemhash]";
print "Interpolate {$arr['itemhash']}";
print "Interpolate {$thevar}yukyuk";
print "Interpolate $arr[5]";

Re:Why I prefer PHP to Perl

[JabberWokky]

Naw, it's just because they use Perl.

--
Evan "it's a joke"

Re:Command Line Interface?

[RealBeanDip]

"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!"

Yeah, that does sound handy. I've been doing it for quite a while using wget and apache+php anyway.

Re:Why I prefer PHP to Perl

[Ponty]

FYI, Java's object model is very close to that of SmallTalk.

And being home on a modem makes the best site around seem slow. Agh, I miss DSL.

Re:Why I prefer PHP to Perl

[Otterley]

Actually, using mod_php with Apache is an order of magnitude faster than mod_perl, particularly if you're using the Zend Performance Suite (nee' Zend Cache) -- it's a cached byte compilation system using shared memory for blazing speed.

We used it at my company and was able to reduce the number of servers used for the given load by 75%. Amazing stuff.

Nice troll, very subtle

[Ars-Fartsica]

Good work laddie

Re:Why I prefer PHP to Perl

[mackstann]

sorry but you're the one who looks stupid, it was a troll, dont take it so seriously. the whole purpose of thought out trolls is to bait people like you into getting angry - and well, he did ;-)

Re:Why I prefer PHP to Perl

[larry bagina]

FYI, Java's object model is very close to that of SmallTalk.

I'd say it's closer to C++, which uses a Simula 67-style OO. Objective C uses a smalltalk influenced OO. Of course, both Java and smalltalk are interpreted, so they're similar in that regard, and Sun cowrote the NeXT OpenStep spec (before Java), so Java does have some Objective C influence.

Re:Why I prefer PHP to Perl

[larry bagina]

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

Rob? Rob Malda? Is that you?!?!

Re:Piping Hot Penis 2.5

[Anonymous Coward]

why was Jon Katz at Wal*Mart?

He heard boys pants were half off!

Comment removed

[account_deleted]

Comment removed based on user account deletion

lame

[Anonymous Coward]

i guess you *like* the bundled GD library because you are too lame to compile it with previous releases of PHP.

Re:lame

[GutBomb]

no, but hosting companys that can't be arsed to compile the good versions of GD won't have to anymore with this new PHP so any hosting company with the latest PHP will be fine for GD users from now on.

Re:PHP is INSECURE!

[Anonymous Coward]

Not as lame as you.

The thing that bugs me about PHP

[Pinball Wizard]

is that you need to get the Zend Performance suite, or at least the Code Accellerator, if you want the best performance from your scripts. Spend the bucks, then your code will run 15-20 times faster.

I'm surprised more people haven't mentioned this.

Re:The thing that bugs me about PHP

[Anonymous Coward]

PHP Accellerator is FREE.

I dont have the URL handy, but a quick Google trip will reveal the URL.

Re:The thing that bugs me about PHP

[Anonymous Coward]

Try:

PHP Accelerator

A free cache/optimizer for PHP.

Yahoo use it on their PHP sites.

Anyone else having problems installing?

[ceejayoz]

./configure results in ...

checking for cURL 7.9.8 or greater... configure: error: cURL version 7.9.8 or later is required to compile php with cURL support

yet ...

[root@server php4]# curl -V
curl 7.10.2 (i686-pc-linux-gnu) libcurl/7.10.2 OpenSSL/0.9.6b zlib/1.1.3

Anyone else having the same problem?

Re:Anyone else having problems installing?

[Compenguin]

do you have the cURL headers etc. installed?

Re:Anyone else having problems installing?

[stikves]

I'm not sure but you may need the CURL-devel packages.

(Ignore this if you already have it or use sources/gentoo/slackware/etc).

Re:PHP is INSECURE!

[Anonymous Coward]

Not as lame as me? It means, sir fuckwad, no matter how secure you're writing your application to pass security information (credit cards, passwords, etc.) between the web browser and the server, PHP is storing your session information in clear-text temporary files. If your server is compromised, or actually physically stolen from your offices, all that valuable customer information is there for the pickings.

I simply don't understand why the PHP developers haven't bothered to encrypt temporary session information. Even a grade school child wouldn't have let that oversight past their code reviews.

Where are the OO improvements?

[TheInternet]

So am I missing something? The early releases of 4.3.0 talked about passing objects by reference, static/private members, etc. Did this get pulled and moved back to 5.0?

- Scott

Re:Where are the OO improvements?

[aint]

It's always been the plan to put the zend2 engine in PHP5. Most likely PHP5 will follow 4.3.x so stay tuned :-)

hypocrite

[SweetAndSourJesus]

You lose just as much for being here to criticise him.

Anyone reading this site would be better off outdoors.

Re:PHP is INSECURE!

[einhverfr]

If you can break into the process (buffer overrun's etc. all the encryption in the world won't do you a bit of good because the key will be accessible to you.

The only real security if you don't trust the administrator is to use the session only as a reference to the real information stored elsewhere. Or if you are storing login and password, split them up and have one in a cookie and the other in the session...

Re:Why I prefer PHP to Perl

[MortisUmbra]

I don't quite understand the need for modding this as a troll exactly....but that's /. for you, if it's PERL/Linux related it's automatically God and the biased opinions and moderations come rolling henceforth.

Re:Why I prefer PHP to Perl

[Zontar The Mindless]

>> FYI, Java's object model is very close to that of SmallTalk.

> I'd say it's closer to C++, which uses a Simula 67-style OO.

Java, like C++, Java and PHP use class-based inheritance.

JavaScript (aka ECMAScript), on the other hand, uses prototype-based inheritance, which is more like that of Smalltalk. Perhaps this is what the first poster was thinking of...?

Re:PHP is INSECURE!

[Anonymous Coward]

You little Troll,

encrypted session information is something noone needs. If you do not trust your server well, than it is your problem, that cannot be solved by PHP. You can always lock the session files in a directory that is only readable by the webserver user. If the session data would be encrypted
there would be some way to decrypt it and the key
must be stored somewhere... Most probably you
would store the key somewhere on the server...

And if you really want overbloated stupid encryption, then you can write your own session save handler (RTFM).

Re:PHP is INSECURE!

[Anonymous Coward]

Why would you store that kind of thing in a session cookie to begin with? You'd have to be retarded. A real developer [like me ;)] would use the PHP session ID as just that, an ID. The real data is keyed off that ID and lives in SQL somewhere. Therefore no passwords or anything else are stored in the cookie sent to the user, or the /tmp/sess_xxxxxxxxxxxxxxxxxxxxxxxxx files.

Re:Why I prefer PHP to Perl

[slamb]

You're not getting it. I know it was a troll - I said as much. I'm angry that the moderators were so stupid as to mod it up. They apparently believed it was genuine.

Re:PHP is INSECURE!

[Anonymous Coward]

You god damned cocksucking motherfucker! You're about yay-shy of being a fucking terrorist!

OS X compatibility

[wevah]

I didn't see this mentioned here yet, but PHP 4.3.0 finally supports out-of-the-box (so to speak) --with-apxs compiling. No longer do I have to try to tweak the configure script or the makefile in order to get it to compile!

This also means I and other OS X users don't have to wait for Marc Liyanage's package to come out (as he is away on vacation now)...

Re:Command Line Interface?

[duncangough]

I was beginning to wonder, no-one else seems to have mentioned this - and after all the discussions that went on just before release too.

PHP-CLI is a good thing for PHP, and I can't wait to start using it. It'll be interesting to see how Perl reacts too, with Perl 6 some way off, and PHP taking a big bite of out of their territory, and especially since both of them have somewhat individual implementations of OO code ;-)

Mods on drugs again?

[Anonymous Coward]

The original poster asked about documenting PHP functions, like Javadoc, to make it easier to read programs. A comment about the PHP documentation was moderated to a +5. Why? The original poster was asking for something completely different.

Re:PHP is INSECURE!

[Anonymous Coward]

Moderators on drugs again? The above was moderated upward.

Encrypt session information? That's insane! Do you really want to do processor intensive processing on files that are read and writen on every hit? Besides, the credit card number wouldn't be a session variable unless the programmer explicitly made it one. Variables aren't automatically saved in a temp file.

There is XML module available

[horza]

I too would love to see XML natively available for PHP. I've written a module that gives a nice simple API to XML, it's available here, but the problem is it needs to come with PHP as standard for it to become widely used.

Phillip.

Re:Why I prefer PHP to Perl

[JasonAZ]

Perl and PHP have two very different philosophies. On one hand, PHP strives to be a language whereby changes can be made quickly and easily. It's a very web-based language, so those OO features are not the main focus, but more as luxuries, whether you have time to implement them. PHP is the ideal language for web-based programming. Don't get me wrong, Perl is excellent, but PHP is for a different market. There is now a new measuring stick for web-based languages--Perl will always be needed, but it is for a different use.