Just read this article, and decided from now on I will refrain from using == unless I really have no other choice, and use === instead.
A bit of a tough read, but very interesting: http://gynvael.coldwind.pl/?id=492
Especially the bits about STRING vs STRING are s-c-a-r-y :eek:
Let's gear this in the right direction, as I believe there could be uses for discussion on this topic. If you reply, "I like the article", or "that was interesting" or anything in between, be prepared to receive a fluff warning.
Please state what the article provided you with personally. Did it open your eyes to something you never knew? Did it make you all of a sudden understand a bug you've been trying to track down for the past few weeks, etc?
Do you have some recent examples where == produced unwanted results in your project and you had to switch to === or a different means of validating your condition?
To start things off, I've been using === and !== for years. I've been bitten more times than I can remember when using == or != to know that using them would be dangerous. Having input come in as a string being compared to a number constantly riddled me with unwanted results. It didn't take long before the use of === and filter_var (or casting) found their way into my toolset.
I remember when I first was learning PHP and finding out about this - I never understood why something with typed variables would allow comparisons like this. Especially with how half-***ed the conversion operators work. ugh!
Luckily for me, I learned about the === operators from day one and always used it.
I knew there were problems with that operator, but damn. I'm going to have a hard time getting away from it as I deal quite a bit with type juggling comparisons ((string)'5' === (int)5 //false (string)'5' == (int)5 //true) due to using MongoDb and constantly reading from CSV files. I did write a class to autocast within PHP, it works quite well so far, but I don't want to have to type cast everything I touch.
Those are some really out of the way corner cases in my opinion, even the string ones. Maybe it's just me, but if you find yourself wanting to use === on every comparison maybe, just maybe, you'd be happier building your site with Java, C++ or the like.
And as bad as PHP is for these sorts of shens, Java Script is worse.
Still, fixing these problems is the sort of BC nightmare that can't (or shouldn't) be done at the Minor revision level (that's a laugh. 5.4.0 is how different from 5.0.x now?) PHP 6 will need to be, in many ways, a do over. But who's going to pay for it, and if it's radically different will the PHP team be caught like the Python team dealing with two distinct branches of the code.
I already knew about "==". Am I forbidden from telling ScallioXTX that I think he found a good article? I've never been a fan of the fluff rule. SitePoint (and vB in general, as far as I'm aware) doesn't have an upvote feature. There's no other way for us to express agreement except to post and say, "I agree."[/ot]
I suppose I'll add an anecdote to make this less fluffy.
I remember back when Perl was the standard and PHP was new. PHP seemed to make every amateur mistake in the book. In addition to the bizarre "==" behavior, there was registered globals, magic quotes, broken URL-encoded parsing (it's actually still broken; we're just accustomed to it now), little or no OO support, little or no multi-byte support, and many other issues I've probably forgotten about. It boggled my mind why PHP was becoming popular.
Don't forget about "Safe mode" yuck
Indeed, I also wonder every now and again why PHP is so popular. It's not like it's the best language out there. I guess it's mostly due to it being easy to install so a lot of hosts installed it. Quite frankly, I would be quite happy to switch to another language, like perl, or Google Go, or maybe even something like erlang. And for those wondering, no, not Node JS.
Yes, it is always to the programmer to use the tool the right way. But it becomes quite a pain when a language has multiple right ways for some things and no right way for others.
For PHP 6 I'm hoping they will finally clear up the needle/haystack mess, use Exceptions for everything, and stop returning false for functions for which 0 is also a valid return value. Also get some consistency and change weird names like tempnam to tempname, etc, etc (I could go on for a while, you get my point).
All, nice, all unlikely, unless they use a legacy namespace to bottle up all the legacy functions.
Plus it runs on a variety of operating systems (including Linux) which makes it a relatively "free" server when it comes to software (no licenses required). Of course, you still need someone with the know how to set it up, and set it up right, but that was a big advantage for the language.
Seconded! I've wished for that for a few years now (darn you .NET and the ease you make multi-threading become!!).
I'm not picking on you, ScallioXTX, I'd just rather not quote the whole thread.
As Mr Lerdorf once said, "PHP is ugly. It was meant to be ugly. If you don't like ugly, don't use PHP."  It's not the best language out there, it's not even pretending or trying to be the best language out there.
I'd rather you (if you'd be so kind as to indulge me) not consider "switching" to another language. By that, I mean PHP is just one tool on your tool belt. Let other languages be more tools to play with: don't just swap your hammer for a scalpel. PHP will always, hopefully, have its place as a quick-and-dirty scripting language to just get stuff done. It may persist as something less "dirty" given the progress over the years, but I hope it will keep the rough-around-the-edges feeling.
All of which are terribly unlikely, whether you like that or not. For starters, the "needle/haystack mess" is really pretty consistent when you take a look at the string and array functions using "needle" and "haystack" parameters (have a look-see): if you were to broaden the scope of that mess to "argh why must I check the manual [or intellisense] for the parameters for every single function?!!! GRRRR!!" then I would be more inclined to agree with you.
Exceptions for everything has been discussed many times over many years by many people: it's still being discussed today. My own point of view, which you're more than welcome to disagree with, is that not everything in PHP is Exceptional. The last thing on earth I want to see happen is my script to bubble up an Exception because of some little notice that I can and have been thus far ignoring. PHP is forgiving, and I like that. I'm also ignoring the "returning false" point for now. Finally, what you might see as weird names another developer sees as old friends. PHP is primarily a glue language—a thin layer over lots of C libraries—and makes use of the underlying function names in the userland function API. The tempnam() function is a perfect example.
As for the original topic; my own concise thoughts on the matter can be boiled down to "go find a strictly typed language to play with" (really, do!).
This is what I don't understand. It drives me crazy. PHP has the audience of most beginner developers as it is THE language of the web. Fix this ship up and let it move onward, not even out of web, but give us the tools necessary to start creating new techniques for web as well as desktop.
Even other loosely typed languages do a better job. For example:
"foo" == 0
The PHP team is fairly set in their ways. Also, there are language design mistakes throughout PHP that cannot be undone without major BC breaks. I don't have the time or the skill to fork it, though if I did I would.
Sweet, the discussion did ensue and progress
My personal thoughts are that he was referring to the order of the parameters (which is particularly noticeable with the functions that contain needle and haystack) are consistently in different orders (which I agree is true for other functions too, maybe not as noticeable though). This will be hard to fix, unless they implement it on a new namespace (as Michael Morris pointed out). However, that would need to be done in a wise fashion that is extendable towards the future, .NET did this several times and I think they managed it well, but it is definitely not to be taken lightly.
Again, I think that would be the point. If PHP considers a situation as a breaking error (think illegal cast, trying to act with an object that is null or unset), then those situations should produce exceptions now that we have them, but I digress, that change could be breaking for some production systems that depend on errors being presented as is (since it seems two different handlers would have to exist, set_error_handler and set_exception_handler -- granted not hard to fix in your code, but it does lead to a "functionality breaking change")
I think PHP has its plus and minuses, for me the plus is being able to quickly spin out code without having to compile it or set it up through configurations or "special project types". I like being able to quickly spurn out a CLI test or process for a proof of concept before spending time developing a full blown system. Could I do that in other languages as well, probably, however, I when I tried a few other languages things got in the way. Ruby kept trying to out-smart me by doing what it thought I wanted to achieve but I really didn't want to take it "that far". Perl was fine (no real complaints, but most systems I was working on didn't have it). Bash has worked well for times I just need to do something quick and dirty that will manipulate the file system or quickly allow me to repeat a task I do frequently (but try and go in-depth and you have a mess of code, that could easily be broken up better in PHP).
Although PHP's intention was never to become a big player in the world of programming languages, it did and I think it is finding itself in a odd position where it can either adapt to its status in the programming world and fix the underlying issues it has had since its inception, or it can sit idle implementing a feature here and there to keep it a relevant language. Time will tell if one path should have been taken or if it will still be "not that big of a deal" amongst developers and the industry.
<h1>PHP, PHP.NET</h1> (think search engines will actually pick this up as an h1 tag?)
I want this statement to start to show up in some search results for PHP in the hopes that it may reach the developers. I'd have it plastered all over the web if I could. Developers grow out of this language as I have been, due to it's shortcomings. This should no longer be the case given it's status.
I perform string comparison in php is the same as C – strcmp and strcasecmp. I haven't used == in years when comparing strings considering its inherit short comings. I don't really think I have used == when programming in PHP at all since discovering the problems with it.
When talking about function ordering and naming that isn't really an issue that should be taken up with php but C. PHP is mostly near direct API to the c string library. Except in PHP we don't have to worry about memory allocation, static libraries, shared libraries and all the other fun things that come into play when dealing with C directly. I think a lot of people that complain would do less if they really had to deal with C. I have had to deal with some C code lately for a custom PHP like interpeter and my appreciation for PHP has significantly grown because of it.
Regardless of the short comings go try to build a web app with C and see how far you get. I think you will have an entirely new perspective when it comes to PHP.
If you use strcmp a lot you might want to have a look at http://danuxx.blogspot.co.uk/2013/03/unauthorized-access-bypassing-php-strcmp.html.
That's like saying "If you don't like being slapped in the face, try getting kicked in the stomach; you will appreciate being slapped in the face after that". I'd rather not get slapped or kicked at all.
There was a good post over at phpsadness about this as well: http://phpsadness.com/sad/47
Interesting, I always use the type safe equality operator either way.
next page →