Slashdot Mirror
PHP 5.1.0 Released
kv9 writes "A new release of PHP5 is available. This version includes over 400 bugfixes, performance improvements over the 5.0.x branch, new date handling code, new versions of PCRE/SQLite/PEAR and over 30 new core/extension functions. A number of security fixes are also present and users are recommended to upgrade."
You mean, it sucks less than the previous versions, and the problems with inconsistent "design" decisions, half-assed attempts at support for objects, etc. have all been fixed?
Wow! I gotta' get me some of that...
MySQL support has been droped in favor of using simple flat text files. The performance increase from this has been HUGE and the feature set is the same.
Really? All my friends and family use good old fashioned PCP.
> A number of security fixes are also present
I think we've finally found a replacement for the security disaster known as sendmail -- PHP.
My other car is first.
While the parent is a bit of a flamebait, he actually brings up a few good points; especially regarding inconsistent design decisions.
In fact, reading through the php_internals mailing-list is one of my favorite things to do - it's hilarious!
...and still no damn fucking namespaces.
Go PHP, ride on to the 20th century!
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
Rails still isn't a language, it's a framework.
(calling Ruby a "toy language" when comparing it to PHP is hillarous though, thanks for the laugh)
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
You don't have any classes named Date, do you? It's an extremely uncommon name. Good thing we have namespaces.
http://news.php.net/php.internals/20352
My Mom likes PHP too! However, I don't see what it has to do with /.
May Peace Prevail On Earth
That's for sure. Ruby might not yet be of perl's power, but it definitely isnt a toy. It is at least as capable as Python and Perl, just not quite as popular.
I am Spartacus
Yeah, putting PHP stuff Slashdot's PHP topic makes no sense.
[sig]
I was under the impression that when using a x.y.z -versioning scheme, bug fixes should be released with increments of z, new features with increments of y, unless they break compatibility, when x should be increased. But when has even PHP done some something in a standard way.
"(...)and over 30 new core/extension functions."
Ugh. Adding still to the inconsistent, namespace mess, PHP functions have? Worst. Decision. Ever.
It takes a man to suffer ignorance and smile
Be yourself no matter what they say
It's widely known that PHP is used by a lot of "developers" without much background in writing secure software. As such, the coding techniques used are often less than ideal, and have lead to numerous security problems in the past.
Are the PHP developers actively doing anything to help prevent those without much experience from writing code that can lead to a server being compromised? Not that they should restrict those few developers who do know what they're doing, but they should perhaps be taking a look at making it far more difficult to write dangerous code.
On the hardware front we have AMD and Intel adding support for non-executable stacks to their processors, for instance. GCC has StackGuard and StackShield. I think it's time for the PHP developers to step up to the place and try to limit the possible damage that can be done when using PHP incorrectly.
It's easy to continually blame the inexperienced PHP users for writing insecure code. But I do believe that it is up to the PHP developers to use their skills to help mitigate such problems.
Cyric Zndovzny at your service.
It's really vague to compare two languages' "power". The only definitive comparison you can make is whether they're both Turing-complete. In that case, Perl = C = INTERCAL = Unlambda.
Laws do not persuade just because they threaten. --Seneca
Zend refuses to add basic features such as a basic accelerator ( PHP scripts get recompiled on every request ). In fact, there was a rumor that Zend bought and killed http://sourceforge.net/projects/turck-mmcache/, the best accelerator out there because it competed with their commercial product.
I understand that money has to be made for development to continue, but that's no way to compete.
PHP server needs true session and application scope variables. File-based session variables it has right now means that any variable that's not serializable ( eg. file descriptor ) can not be saved in the session scope. This is a huge problem. It results in developers making countless round trips to their database to serialize data, and hence making PHP scripts more dependant on close/performant database in general. There was an mmap based solution being worked on, but haven't heard much about it lately.
Other web environments have had these features for years.
I'm guessing that that sought of restriction on the PHP server will continue until an alternative server is developed and begins to gain popularity.
Based on upvotes, Ageism is the only "-ism" Slashdotters care about and think isn't SJW
I use to use PHP a lot day to day for several years (lamp), and found it kicked the ass of ASP for doing really fast web apps. Bigger web applications however, is where its mechanics started to erode - specically includes and the old module level variables issue.
.net and seems to be stuck between a scripting language and a fully fledged OO language.
PHP 5 brought more OO features but it's still loosely typed and not compiled, meaning its OO features pale in comparison to JSP and ASP.NET. Until these two features are added by default (yes I know there are compilers), I can't really see how people will want to make use of its OO features in a business scenario. It handles strings (atleast in 4) about 50x slower than
Nothing costs nothing
I'd like to take this oppurtunity to complain about __autoload in PHP5. It is one functionality which I find tremendously inconvenient when coding something like APC . File inclusions were never supposed to be that dynamic, it ends up with different compilations of the same file for different places it is included in (apparently some are still fighting).
Quidquid latine dictum sit, altum videtur
What are the backgrounds of the main PHP developers? Do any of them have any serious credentials, or even background in language design at a graduate level, for instance?
One thing I find about PHP is that, rightly or wrongly, we always hear about how it's quite lacking as a language. Could that be because it is designed by people who have very little experience designing modern programming languages?
Cyric Zndovzny at your service.
Are there any good (shared) hosting companies that support PHP 5(.1). Most of the ones out there seem pretty old in the stuff they support, with Apache, 1.3, a 2.4 kernel, running mysql 4, and php 4. Are there any good hosts out there that run new software? I know the old stuff is reliable and works, but sometimes it would be nice to have hosting with cutting edge tools, when stability doesn't matter so much.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
I had one of those too. I use Virtual Hosting, and so give everyone slightly different versions of my e-mail address -- then I can tell who's been selling my address on.
The one they used to contact me was one I had supplied in an e-mail regarding the nVu HTML editor. {In the end I couldn't get to grips with it, and went back to kate, which -- like most of KDE -- has gone from strength to strength}.
Je fume. Tu fumes. Nous fûmes!
Some of us are trying to help the situation by educating PHP developers. For my part, I try to write articles (and make them available for free), give talks at conferences and user groups, and answer questions on mailing lists and forums.
There's also the PHP Security Consortium, the Zend Framework (which will hopefully include most things on my wishlist as well as solve other problems), and a new input filter extension.
As BP says, it's a start.
It strikes me as odd to suggest that they take security seriously, yet it will take them to version 6 to get something that is remotely becoming secure. Not only that, but it sounds like they've had to take such security enhancements from the Hardened-PHP project, rather than implementing it on their own.
Cyric Zndovzny at your service.
FYI (if you didn't know already), nVu is funded and developed by Linspire, so it's unsuprising that they signed you up for the email list. I bet the privacy policy even says so. So while I know that it's annoying, it's not that nVu sold your email address to Linspire, or (neccesarily) that Linspire buys email addresses - nVu *is* Linspire.
- IBM has spiffed up Cloudscape to be somewhat compatible to DB2, renamed it to Derby and is giving it away
- Oracle is giving away a mildly crippled version of its DB, I don't remember the exact circumstances
- ADABAS, also known as SAP DB, is now also FOSS
- Firebird, née Interbase, was freed years ago and is said to be working well and under active development. I don't know why so few people seem to like it.
- I believe I heard about SQL Server being "free" under some circumstances too, but I'm not sure.
So... many thanks to MySQL for being a forerunner in the "free DB" department, and more thanks to other, formerly proprietary-only vendors for making their products a little more accessible to the common man!When one person suffers from a delusion, it is called insanity. When many people suffer from a delusion it is called Rel
MySQL support has NOT been dropped!
If anybody is interested in what is coming up in PHP6 you can read an overview here. Looks like the main push of the next release is to stop people coding things wrong (by depending on register globals and magic quotes). Oh and the small thing about adding Unicode support. Unfortunately this will probably mean a slower adoption than PHP5 as it is likely to break popular scripts (such as forums, blogs etc) which will mean that Hosting Companies are unlikely to touch it till the script writers update their scripts.
... still having no namespaces and lacking in full-blown OOP and all.
So what?
PHP is the web generations basic. No more. But no less either.
Given that loads of very usefull webapps out there are built in PHP
I'd say the criticisim is mostly inadequate whining. If PHP doesn't
cut it for your job, take something else. No big deal.
We suffer more in our imagination than in reality. - Seneca
[X] Microsoft ?
I have been developing (or trying to develop) web apps with PHP for a couple of years and I dislike it more and more every day. I realized it was a shitty language upon discovering that there was no way to avoid loading my application classes and objects with every damn page view, but the single most irritating "feature" for me is that an included file does not "know" where it lives in the directory tree, so that if you want to include another file from the included file (to properly use an esoteric and modern feature like inheritance), PHP will not look for it relative to the first included file directory, but to the ORIGINAL SCRIPT position! Forget about any system variable that tries to tell you where you are, as those do not work consistently across versions, systems or whatever. You are basically precluded from using anything but absolute pathnames in your include files if you plan to include the same file from (gasp) scripts in different directories.
Now that PHP is popular it is undergoing something of an identity crisis. Rasmus said it was an answer to "the web problem", a very simple answer. A "right to the point" approach, terse rather than elegant.
But as more "serious" developers pick it up, more "serious" features are requested.
The fact is, if you're flexible you can build whatever you need in PHP4. It may not always be the way you prefer to code, but you can do it.
PHP is what it is. And it won't appeal to everyone. Fortunately there are many other platforms for the unsatisfied. Take your pick.
If your primary gripe with PHP is that it isn't enough like Java, shut up and use Java. Same for - insert language here -
I am very interested to see the new framework being promised by Zend and IBM. (http://www.zend.com/php-collaboration/) Can they really deliver on their promises? If not, I do predict a mass exodus to ROR. PHP could wind up being relegated to individual scripts or 5 page websites.
I currently code in php (and use MySQL). I like some of it (a very rich language), but dislike other bits (a very rich language). Its like a programming language designed by a programmer, but that doesn't necessarily make it any good. Can someone give me a list of alternatives? Someone mentioned Ruby, I will look into that one. Any more?
Strange how this bug doesn't even show up on a search, but punching it in manually brings it up, and google shows you where it is.
Apparently the ticket hasn't been touched since it was reported 16 months ago.
It's so widely deployed, yet is still very much a language in development. Core changes are made frequently which break compatibility with previous releases, it's very annoying and frustrating for a developer to keep up with this sort of thing, considering that PHP isn't the only language needed to be known. Poor are the folk who have to keep up with the latest programming fads. The world needs more standardization. PHP needs to be standardized, with no more drastic changes/extensions made to the core. After that is done, tweaking performance and security should be focused on, considering the nature of PHP.
Couldn't one abuse classes as namespaces?
The only thing missing is the ability to alter the class def a la adding "friend"s
I'm still trying to figure out what people mean by 'social skills' here.
Mysql's "amazing speed" is only for weak benchmarks of a single user running queries in serial. Once you start having many users running many different queries at the same time, its performance falls apart. This is where the mysql speed myth comes from, people comparing 100,000 simple select statements in serial for mysql and postgresql, and mysql being faster at it.
Mod the poor guy back up, PHP's mail() function is completely retarded. I have never seen a single PHP contact form that isn't exploitable to send spam because of this nonsense.
In fact, there was a rumor that Zend bought and killed http://sourceforge.net/projects/turck-mmcache/, the best accelerator out there because it competed with their commercial product.
Did they not buy and Kill Turck MMChache but hired the main developper to work for them thereby "killing" the project.
IMO PHP is great for doing many things it will never replace C/C++ or JAVA but its a quick and simple solution. and Yes there are many bad php scripts out there. theres also a really bad web browser with many security holes let it go nothing will ever be perfect.
Yes there are many features that could use to improve itself but the idea behind PHP is quick and easy. the cost of bulding a program usually rely on the programmers not on the hardware and if you are into making a big site just install APC yourself who cares if a compiler is built in the default. for your default needs it doesn't matter hardware is relatively dirt cheap to your programming costs. What makes php so good and popular is that to write to the screen you don't need 4 classes of buffers and such you go echo to get the contents of a file be it web or not you go file_get_contents(http://www.example.com/ and voila you get stuff done quicker. its not optimized but really you'll get more impact on a script if you have a good algorythm than if you do some real hard core optimizations (like taking MM turk over APC or another that compile first the scripts)
and lets not even talk about the community surrounding PHP with so many open source classes to speed up development. that the power of PHP.
As a side note my wishlist for PHP includes overloading and type hinting/auto converting before namespaces.
Ruby has the exact same problems he mentioned. How is a weak, dynamic typed language that is not compiled supposed to solve his complaint that PHP is a weak, dynamic typed language that is not compiled?
He is wrong though, PHP is compiled. Its just compiled every single time you request a page, making it slow. Accelerators exist to compile PHP once and then cache that. This is not possible with ruby because it is not compiled, it is interpreted.
Since when has the "If you don't use it, stop complaining" attitude been acceptable? I don't use Windows, but I'm constantly pointing out its faults to people so they're less likely to get infected and have their computer send out spam. I don't smoke, but I'd rather point out the dangers of smoking to someone than let them cut ten years off their life.
A while ago, I tried writing my own blogging system using PHP, because it would be easy to find someone to host me. I kept having to look things up (isnull or is_null? arrlen or array_length? (neither, it's count)), typing mysql_this, mysql_that instead of using namespaces is annoying, lack of a good scoping system very annoying, etc etc. I did want to use PHP, but didn't, because I thought it sucks. Would you prefer it if I didn't say anything, and just let the PHP guys carry on with the mess they've made? Hint: that wouldn't accomplish anything.
"PHP is the web generations basic". Oh great, the web generation is growing up thinking that mysql_query( $_POST['input']) is a good idea. After all, magic quotes will make sure it's safe, so gets(input); system(input); in C should be safe! Intentionally or not, PHP is the first language learned by many people nowadays, so it should at least educate them into good practices instead of just doing stuff for them. (Doing things for the user is one of the things that Microsoft gets flak from here, too). PHP tried this before, with register_globals, and look what that turned out to be.
Surprisingly, people actually want to make PHP a better language, but apparently any complaints should be met with "Don't like it? Then get lost!", leaving PHP as it is. Oh well.
Guy asked me for a quarter for a cup of coffee. So I bit him.
PDO is the first API/extension in PHP that looks like it was designed before writing.
That's big step away from MySQL and magic_quotes mess.
The new version of Postgres does have a version of table partitioning. Ain't tested it, don't know how much of an improvement it does on large table scans..... but still.
WHo cares? PHP-5.1 introduces PDO from pecl into the mainstream distro. The idea of course being that it doesn't matter what is behind your scripts as long as PDO is used. Consider it DBI essentially. So your app can work with sqlite, mysql (transactions or not), postgresql, etc. in a much more consistent manner.. Sure there may be slight variations, but stick to the SQL spec and you should be okay.
-M
when you see the word 'Linux', drink!
You sir, should never program.
Always validate all input provided by the user that is used in any way. If it's in a database you're smart enough to escape it (or use query replacement methods that do it for you). If you're sending mail, you damn-well be sure it's an e-mail address. You have RFCs to guide you on this:
http://www.w3.org/Protocols/rfc822/
A field-name consists of one or more printable characters (excluding colon, space, and control-characters). A field-name MUST be contained on one line. Upper and lower case are not dis-tinguished when comparing field-names.
It defines what characters are valid, and if you are about to pipe whatever data you accept into an e-mail, that's something YOU decided to do.
IT IS YOUR JOB to make sure that what you put beside FROM: (or anything in that parameter) is an e-mail address. It shouldn't have a newline. It shouldn't have escape characters. It should probably contain only a limited regex. Would you put an SQL query someone enters into a database? Then why an e-mail address to sendmail?
On a side note, the only way around this is to have a programming language that tags data as tainted if it came from or was derrived from user input and not allow it for input, and having functions that sanitize data and remove that flag. This is first off slower and second not optimal in many situations.
when you see the word 'Linux', drink!
PHP is getting considerably better actually at being (a) a mess, and (b) making you learn by mistake, (c) providing simpler frameworks.
This is what PHP 5 and PHP 5.1 are all about. Lets fix the problems in the language and those things that go back to it's origins. PHP at one point did little more than a shell script, and now you have endless numbers of modules, extensions, and database backends.
You'll notice they have E_ALL on by default and highly encourage E_ALL|E_STRICT to be used for good coding practice. You'll notice register_globals is off by default. You'll notice countless quirks are virtually eliminated. magic_quotes are off by default because it's become apparent they don't always work and it's better done by the database engine (which can escape what it needs rather than just slashing random things).
You'll notice in 5.0 and 5.1, they pulled out extensions that are specific or not maintained (payflowpro, fileinfo, and many others) to PECL.
You'll notice they are recommending mysql extensions and others aren't use. You'll notice they're even advising that mysqli isn't used. You'll notice they are focusing on PDO to simplify and eliminate the ~10 driving extensions for each database engine with their own unique ways of doing everything with a universal framework (note: PEAR::DB is written in php classes- this is C and good code).
This is all a method to fix those problems everyone keeps complaining about. It's a pain, and creating even more complaints in the process of broken scripts, classes, and tools with the removal of things like is_a, call-time reference passing, and others- but once these scripts get fixed, and over time once everything goes PDO--- You'll find clean and swift code without much trouble at all.
Give it 6mo for the whole php 5.1 thing to migrate into various popular scripts and you'll find the world will be better for it. It's all in the master plan- simplify. Note that while many things have manual sections, much of it is in PECL and not the distro. At some point that should really be pulled into its own manual making it easier to find the core topics. That's just my opininion.
-M
when you see the word 'Linux', drink!
Mathematical proof of why PHP programmers tend to be stupid.
Persistent objects are super, but think of this from a systems perspective. I'd imagine you're thinking of Java, having a nice super-server running and then a small component in Apache sending the actual requests to the Java environment. Now take PHP:
- each apache process takes some requests. Opening a file-descriptor or database connection in one doesn't mean it'll be available to another process. So the file needs to be opened, database connected to, etc.
- persistent connections (database) are only useful if you have a database and single/cluster of web server(s) using that single database connection/username. Look at shared hosting. 500 apache processes, 10 web sites with different credentials. So you expect the database server to be able to keep 5,000 connections open? The next request by that user for the session may not come back for 8 hours, so why would you keep a connection open?
- Locking issues with keeping files open maybe?
Make a class or function that serializes a file. Now of course that's not possible, but emulate it. Find the file position, save the file name and info about it. Then when you reload the session fseek the file and all is well.
Keeping such things (file descriptor/database) with the session is silly in most cases, as there is little gain in most cases.
-=-
So make a php accelerator. Who's stopping you? Introduce it to PECL and people may use it or make a patch. Zend Accelerator (not the optimizer which of course they keep closed due to the encryption abilities- not to mention minimal performance gains), is far from optimal for 99% of Web sites out there. turck-mmcache was the same way as well. If you run a single site, it works fine. As soon as you have multiple sites, and you start caching files, database calls, and output, you have SERIOUS issues unless you know the application. Suddenly your script isn't running as it should some of the time.
-M
when you see the word 'Linux', drink!
core_defines.php
Have a base controller include that one core_defines.php file, the
include(CLASS_PATH."foo.php");
Yes, it's not the namespace support you're talking about, but it's much better than having all your include() statements use "../../../" notation in them. There are two primary issues with that approach.
1. The path where you store those files might need to change for some reason.
2. It's not as clear from looking at it what type of file is being loaded unless you have class_*, lib_*, and other filename prefixes on each file. include(TEMPLATE_PATH."/foo.php") is very easy to guess at the intent of the include statement.
What I *don't* understand is how using autoload makes this process much easier. If I reference a class that's not yet loaded, autoload() will get called with the name of the class. It seems I would need to have potentially loads of paths to check in the autoload() function to 'find' the particular file I wanted, and hope that it didn't find another class of the same name in another directory before it found the one I was looking for.
I guess you could just push all the paths on to the include_path setting, but scanning multiple directories has its own performance issues. It seems to me that simply being explicit about what packages a particular file needs to execute is, in most situations, the best. Yes, it's a bit more, work, but being explicit makes things easier to understand.
creation science book
Yes, one can kid-of-emulate namespaces using classes (AFAIK people have done it in fucking Javascript for years !).
But
To sum it up, yes you can use the oh so shiny new PHP classes to create namespaces, but that's a hack, and a quite bad one.
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
but is it compatable with the 150 separate pages of php i have written that have dozens of queries hard coded
+1 insightful
It's not always about writing code that's convenient for yourself, but is easy to read by others (or yourself 6 months later). By forcing the 'global' keyword, PHP helps keep the code readable. Granted, there's many other ways to make PHP unreadable and unmaintainable, but this isn't one of them.
creation science book
You sir, should never make rediculous claims based on absolutely nothing. I should never program because I think the PHP developers shouldn't write a language designed to be easy and appeal to newbies, and then make functions incredibly easy to misuse? Get your fucking head checked. I do validate my input, and I don't use PHP. How well I can program has nothing to do with it. PHP should not make their language as easy to create exploits in as possible, for no reason, and refuse to improve the situation despite constant abuse from the hordes of inexperienced programmers that PHP caters to.
And there is another way around this, PHP's mail function should take a "from" argument, instead of forcing people who don't know what a header is to create the from header themselves.
Why, oh why, was the scoping done so utterly backwards?! I was cleaning up some code, moving it into a function, and suddenly it stopped working. I had realized the answer the first time I tweaked it, but summarily forgot the second time around. What was it? Why, naturally, I had forgotten to do 'global $foo' inside my function - how stupid could I be to think code inside a function wouldn't pick up the contents of the variable as declared outside it?
Why, oh why, are you creating a function and not actually mandating that anyone pass in functions? You're obviously changing the original code to *call* the new function - why not actually pass in what variables you need rather than rely on 'global'?
Why, oh why, can I not have something as basic as 'microtime()' in Perl, instead having to rely on Time::HiRes? Having so many external CPAN dependancies makes the code very system dependant - moving to a new server might mean that your code won't run because a particular CPAN module isn't installed. Not that you *can't* get it running, but it's a pain. PHP avoids a lot of that by having many useful functions 'built-in'.
creation science book
Why, oh why, are you creating a function and not actually mandating that anyone pass in functions?
That should have read 'parameters' not 'functions'. Oops...
creation science book
The Releases page doesn't show the PECL download. Nor does the downloads page. I hope this is just an oversight and will eventually be corrected.
The Russians have won. They have made the world a cesspool of distrust, greed, fear and hate.
I tried installing 5.1.0 this morning, and it broke phpBB (the latest version, whatever it is) - phpBB could not log me in. No errors or anything, just no login. I know they've had compatibility issues with PHP5 before, but never anything this drastic. I went back to 5.0.4 until someone gets it fixed.
Did you profile the system, before or after, to find out where the slowness was? If your code improvements made the system get faster, what made it get slower? Increasing traffic?
What makes you think that having transactions would improve performance? There are good reasons for wanting transactions, but performance is not one.
Ever since they updated the Zend engine after 4.3.6 things have been going wrong. There are still bugs with variable references and memory management that appear in obscure scenarios that are hard to replicate but they're definitely there. I'm starting to lose hope in PHP as a stable platform in the wake of recent developments.
Java used to be regarded as a horrible language for the web, but ever since GCC included a Java compiler, it's actually beginning to be fast enough to be worth the hastle.
Now, a PHP front-end for GCC would be an interesting project, and could offer some serious competition to Zend. Which means it is likely to last all of three seconds before being found dead in an electronic alleyway. However, as it stands, the syntax is horribly inconsistent and not particularly generic. For example, I like the fact that PHP lets me use a crypto library, but why should I have to care if it is mcrypt, gcrypt or some other package out there?
In the same way that a database-neutral API now exists for SQL functions, there should be other implementation-neutral APIs for all of the other libraries. Forcing people to hard-code is a mortal sin and verily should thine hard-code-forcing-coders be delivered unto the rabbit at Aaaargh.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
I started off doing web coding in PHP 3 years ago, and was even pleasantly pleased when PHP 4 came out as it was a real, practical improvement over PHP3, especially as regards sessions and form data. Since then, I've learnt Java, ASP, Perl and Cold Fusion and started on Ruby. (and C/ObjC for native development)
Today, after not having done any PHP for about two years, I took a look at the PHP 5 documentation.
I was appalled.
Back when I started learning Perl, many of the apparent idiosyncrasies in PHP made sense such as the $syntax, multiple variable assignation, string concatenation and others. PHP had made a simpler version of Perl (automatic dereferencing, yay!). Then, when I was reading through the docs I noticed that PHP5 was doing its utter best to ape the functionality of Java (OO, exceptions, collections, interfaces, reflection, overloading, overriding etc) with the syntax of C++ (:: for static members, -> for virtual methods) but with the same loosely typed variables (Just ask yourself when looking at code you've never seen exactly what type does that unknown function return) and no namespaces (Perl, Java and C++ all have this in some form or another) and a huge array of functions that has no consistency whatsoever.
So, in essence, we have a language that is a mix of Perl, Java and C++ but with no real innovation of its own, unlike Python or Ruby, both of which are extremely consistent and remain true to themselves. Even lowly Javascript is far more consistent than PHP.
There is no way that I will code or design a large webapp in PHP. I had to debug a fairly complex one recently and it was a nightmare. I think I'll wait another few years and look what PHP6 turns out to be.
"The point is basically that it has nothing to do with newbies or experts doing the programming."
It has everything to do with this. PHP's mail function is very easy to misuse. PHP actively targets newbies. This is a bad combination.
"It's powerful, despite you saying that it's not."
I said that when exactly? Oh right, you are just making up bullshit to make yourself feel better.
"From the same token, one of the first rules to programming is to never trust the user!"
Rules that 99% of PHP's userbase don't know.
"Note that php doesn't set from by default because many mailers will set it for you to a safe default- often the user account who is sending the mail. So having a from of the user sending mail is a bad default? It's a custom header and shouldn't need to be specified in many cases."
Good lord you are fucking stupid. I didn't say it should set a from by default, I said IT SHOULD HAVE A WAY TO SET IT. It currently does not, there is no from arg. Hence people who have no idea what is and is not safe in a mail header must create mail headers themselves. This is complely retarded.
"And accepting a from address still means that it needs to validate it. Why should mail() validate it for you"
Because that's its job. PHP's mail() function is creating headers for to:, cc:, etc. It is therefore mail()'s job to ensure that the headers it creates are valid. The whole point of it is to remove the job of valid header creation from the user. It should offer a from arg to do this for the from: header as well. If the mail() function isn't going to create valid headers for people, then it should be removed and people can just pipe directly to sendmail. At least then its very clear that users must create valid headers themselves.
"If you want this kind of functionality, try a phpmailer class or make one."
As I already said, I don't use PHP. I want PHP to stop making it as easy as possible for people who don't know much to fuck things up, thus putting spam-abusable contact forms on their websites, on our servers.
Why are all you PHP apologists so incredibly stupid? Not having a from argument does not make things easier at all, you can have optional arguments you know. So if you didn't specify a from arg, then it will use the (often undesirable) webserver user as its from.
I have a handle on this quirk because of getting spam complaints due to people putting exploitable PHP contact forms on webservers I admin. Duh? You have never heard of web hosting before?
"If a newb doesn't know what a header is, chances are the newb shouldn't be trying to fuck with 'em."
EXACTLY THE FUCKING POINT. PHP's mail function is creating the headers for to, and subject, so that users don't have to. It needs to be able to make a from header too. Its stupid for a high level language like PHP to require users to know the inner workings of mail headers. If you have to know what a valid mail header is and how to validate them, then you can just pipe directly to sendmail, so why is there even a mail() function at all?
And of course, this is the second problem. PHP's mail function is simply broken, plain and simple. It is NOT the web developers job to ensure the mail headers are valid, because they are not creating the headers. PHP's mail function is generating invalid mail headers (for the args it does support like subject), that's the PHP developers fault, not the fault of the people using PHP.
I don't think there is a problem with giving a little power to a newb, why do you insist on making irrational assumptions based on your warped prejudices? I think there is a problem with programmers writing broken, stupid code and then blaming other people for it. You claim to "have this thing" about taking personal responsability for being a shitty programmer, but yet insist on blaming the user for problems in PHPs code. If its PHP that is generating the header, then its PHP's job to ensure it is valid. And you cannot have \r\n in a valid mail header. This is the fault of the PHP developer who wrote mail(), and every PHP developer since who hasn't fixed it.