| SitePoint Sponsor |
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
Rémon - Hosting Advisor
Minimal Bookmarks Tree
My Google Chrome extension: browsing bookmarks made easy
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.
<?php//Kyle Wolfeecho devBlog("My Dev Notes");
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.
Off Topic:
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."Originally Posted by cpradio
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.
PHP's only redeeming feature is that it evolves quickly, and a lot of these warts have been fixed. Of course, some warts like "==" still exists, but I can deal with that. Plenty of other popular languages, such as JavaScript or C++, have parts that we consider bad or dangerous. But we can use linters to force ourselves to only use the good parts. For JavaScript, we have jshint/lint. For PHP, we have CodeSniffer. I don't hear about it being used very often, but we could integrate it into our automated tests.
"Folks who know what they're doing make complexity seem simple."
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).
Rémon - Hosting Advisor
Minimal Bookmarks Tree
My Google Chrome extension: browsing bookmarks made easy
All, nice, all unlikely, unless they use a legacy namespace to bottle up all the legacy functions.
True multithreading.
<?php//Kyle Wolfeecho devBlog("My Dev Notes");
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!!).True multithreading.
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." [citation needed] 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.
<?php//Kyle Wolfeecho devBlog("My Dev Notes");
Even other loosely typed languages do a better job. For example:
"foo" == 0
In PHP, this is true (bizarre). In JavaScript, this is false (makes sense).
"Folks who know what they're doing make complexity seem simple."
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.
<?php//Kyle Wolfeecho devBlog("My Dev Notes");
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.
The only code I hate more than my own is everyone else's.
If you use strcmp a lot you might want to have a look at http://danuxx.blogspot.co.uk/2013/03...hp-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.
Rémon - Hosting Advisor
Minimal Bookmarks Tree
My Google Chrome extension: browsing bookmarks made easy
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.
The only code I hate more than my own is everyone else's.
I agree with this. The problem is, the PHP developers are in an awkward position. If they fix some of the fundamental language problems they risk breaking backwards compatibility and considering in PHP we're lucky enough to be able to download a script written in 2001 and in most cases it still work today, coupled with the fact there are many many websites running very old code. Any major backwards incompatible change they make will make people wary of upgrading. Look at how slow adoption of PHP5 from PHP4 was. It was only a month ago that PHP5.3 became more widespread than PHP5.2 and PHP5.3 has been out since 2009.Sweet, the discussion did ensue and progress
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.
PHP can fix the problems, but it will take quite some time for the world to adapt if they do. And.. the longer we leave it? The more potentially incompatible code is written and the harder it becomes for any businesses to upgrade.
I honestly don't know what the answer is. At the moment, the implication from the PHP developers is that their attitude is "Leave it flawed and don't break other people's stuff". Which is a fair sentiment, even if people here and elsewhere don't agree with it.
.NET has gone through similar circumstances and it withstood the test. 1.1 to 2.0 had breaking changes, 2.0 to 4.0 also had breaking changes. Yes, it took time and money to ensure your application could survive, but we simply did what most businesses would do. Install both, and take your time to move over to the new version.
PHP could do that, but really, it may not be a big deal for the PHP world and the group that is complaining might purely be complaining because we work in other languages relatively often and we don't see these idioms staring at us in those languages (granted every language has their own idioms). I personally hope sometime in the future they try and fix some of the mess contained within, let PHP become much more, the world seems to want it... as it sure took to it quickly.
The == I found amusing and also the return values of numerous functions require work-a-rounds to get the function to do what you want it to do
I was familiar with C and Pascal before starting with PHP and found the non-declaration of variable types remarkably difficult to comprehend or to even use confidently. Even now after quite a few years I still think that declaring a variable type and have the compiler scream when the type was used incorrectly would be beneficial.
Also the lazy practice of assuming undeclared variables, even Visual Basic had some optional declaration that variable had to be defined before usage.
I am also surprised that nobody has mentioned the amusing and informative article referenced in the original post:
http://me.veekun.com/blog/2012/04/09...of-bad-design/
Ah, finally, John came along and posted the best What's-Wrong-With-PHP rant I've ever read. However the article does list it at the end as an update.
So, looking at those, let's say a New Wave of PHP devs (core devs) came along and mutinied and decided to pull a Guido. Would that be so bad?
Honestly I don't see Python suffering from having a 2x and a 3x branch. Fixing unicode and a few other big things in 3x just allowed Python to get so many more things added to it. The users are today usually split by framework, or up-to-dateness: if your framework doesn't support 3x yet, or nobody's upgraded your machine yet, then you're still using 2x. Most machines are running both the 2x and 3x interpreters now. Someone started a wall-of-shame listing frameworks who still aren't 3x compliant yet... that number is growing pretty steadily. PHP surely has a larger userbase and prolly larger dev-base... could be done quicker maybe?
PHP has enough wrong with it that, even if most experienced PHP devs feel more than confident that they aren't bothered by these wrong things because they know the language well, a break in backwards compatibility with PHP6 could be accepted. If anything, the more experienced devs would accept it and probably the newbies or lower-level devs would be the ones most against it. And maybe hosters :)
Since I started in Javascript, == was in fact nice to use with form data. Everything inputted in forms is a string, even if you asked the user for a number. Since JS is on the front and your backend should *always* really be checking tainted data, letting == just check if the user's "2" is equal to 2 was useful and nice. No, we don't want to be told that string"2" is not the same as number2 — we know that already in this case. Sometimes you really just want to know if two things are equal, even if they are not the same. The mistake is probably using similar-looking operators. == vs ===? Python decided, use == to check for equality, use is to test if they are the same thing. How many times have we seen new Javascripters saying exactly what the OP said? Lots of times "Wow, I really should be using === whenever I can" etc. Usually after reading The Good Parts or after getting bitten.
At work, we just manually convert things before trying a comparison anyways. We'll never take some form control's "2" and test equality: we'll try int(theFormData) except (whoops it's not even really a number in any way shape or form) and then compare, which is slow and safe(r). With strings we're always worried about unicode anyway (using 2x) so depending on how much work we want to do, there's stuff going on before comparisons there as well. But otherwise, assuming I know what I'm doing, I should be able to ask if two strings are equal (even if they are stored as separate objects in two separate memories), right?
One little hiccup in Python tho, dunno if PHP does this: sometimes small values are sort of "cached" (they're called interned strings, some sort of compiler optimisation) where if you say x = 2 and y = 2, they may indeed be referring to the same object in memory, so x is y will return True. Whoops. This is usually small values and only when in the same scope, but still...
What the article states PHP is doing, though (converting two strings to longs and doubles) is definitely wtf material. You'd think it would check type first, and only attempt interpolation after seeing they are not the same type? I thought Javascript did this. Perl does this: tries to compare, oh can't they're not the same type, sees if it can convert one of the things so they then are the same type, try compare again. Javascript seems to have crappy rules for who it converts to what, resulting in cool stuff as seen in the WAT talk.
Posting Permissions
Reply With Quote
Bookmarks