15 ms·

We will try to stop fixing bugs in PHP

382 points by robbiet480 14y ago

josegonzalez 14y ago
Upvoting, because the issue at hand is so old that I find it funny people will use this as a reason as to why "PHP sucks". For the record, the version in question was 5.3.1 vs 5.1.6, two releases away and three years apart. Of course you'll need to test updates to your app with such version changes. Yes, using semver means this is a minor version release, but if we do that, I'll be first to note the lovely hash syntax changes in Ruby 1.9. In any case, the current release is 5.4.4.
- rurounijones 14y ago
  Sorry I couldn't grok what your opinion on semver was. Ruby 1.9 introduced new hash syntax but did NOT break the existing syntax one so it was a minor version release (backwards compatible). PHP made an backwards incompatible change in their code so it should have been a major version increase. So as far as I can see Ruby is in the right and PHP is in the wrong with regards to adhering to semver. Is that not your opinion?
  - deleted 14y ago
    [deleted]
  - josegonzalez 14y ago
    The following does not work anymore in 1.9 (at least when it was released, who knows if they reverted the change): {"a", "b"} And there were plenty of gems and small scripts online I was able to get working just fine under 1.8.7 but not 1.9. Thankfully that is largely no longer the case, as things have been updated or replaced. String class was also given a nice kick in the ass, at least in regards to iteration. Would you say that these were not backwards incompatible changes? Code that worked before stopped working. Breaks BC in my book. And in both cases the changes were arguably for the better. - Stop writing code with uninitialized variables - Stop iterating over stuff that shouldn't be iterated over in that way As far as why the changes were thus, it was decided to destroy PHP 6 - do people still write books about that? - and port every change other than unicode support down to 5.x. Someone feel free to correct me on that point.
    - petercooper 14y ago
      It doesn't work in the latest 1.9 either. It was a bizarre syntax that hardly anyone used from my experience (I've been a library-oriented Rubyist for several years and never saw it in production code.) However, String is a good point, and especially around character encodings. Not to mention threads, major stdlib changes, enumerators, and more..
    - piggity 14y ago
      I don't "really mind" if it breaks totally (i.e. throws an appropriate exception or doesn't parse the syntax check). I find it much more irritating when the behaviour subtly changes and introduces edge cases that may not be picked up in testing / normal usage.
      - josegonzalez 14y ago
        Passing in an empty string to a function that states it takes float as it's argument is certainly an edge case the developer should have thought of.
        masklinn 14y ago
        The again, in PHP, interpreting strings as floats is not unusual and pretty well defined. So in PHP it's also a case the developer could have considered normal in his expectation that PHP would behave as usual (and it did, prior to 5.3, for this precise function)
        methodin 14y ago
        Not for user-provided input. That's just a dumb thing to do in any language.
        masklinn 14y ago
        > Not for user-provided input. Not what for user-provided input? The source of a string does not matter to this rule of PHP: a string used in numeric context will be parsed and converted, if it can not be parsed as a number its numeric value will be 0. That's it. That's how the language defines strings in numeric contexts. > That's just a dumb thing to do in any language. Sure, you won't get any argument from me on that, but that remains how PHP works and has always worked.
  - gurkendoktor 14y ago
    Somewhere around Ruby 1.8.6, the stdlib Digest::MD5 syntax changed without any explanation that I know. In one patchlevel of 1.8.6, they've added a check against creating new Ruby objects while the GC is running (I hope I remember this right), breaking all SWIG extensions at once. Ruby 1.8.7 changed the C extension API, I think? I'm not sure if 1.8.7 broke the old one or if 1.9 did. Ruby 1.9 broke "when 5:" in case statements. Files also started needing "# Coding: UTF-8" comments. And then there are subtle changes that probably aren't even documented, like [Math.sin 0] not being valid syntax anymore. Block variable scoping and automatic splitting into Arrays is different. Ruby 1.9.2 (!) changed the way require() works and added require_relative() which is impossible to properly backport. And Ruby 1.9.3 fixed a parser bug again, breaking code that worked on 1.9.2. (I think you could have a superfluous "do" in one place.) Those are the breaking changes that I can remember from first-hand experience now, only the last one is second-hand over IRC. And this is excluding Rake, Rubygems and all the other crap that breaks at every other git commit. Ruby is a bad example.
    - josegonzalez 14y ago
      I used it as the example simply because it is normally a language that is touted quite superior to PHP. I think it is better in some regards - building/using Ruby DSLs is awesome - but not all. Languages are subject to bugs. If they didn't have bugs, people wouldn't complain.
      - iamumassthrower 14y ago
        Hahaha. People wouldn't complain. That's a knee slapper.
        sirclueless 14y ago
        No more preposterous than software without bugs.
        josegonzalez 14y ago
        At that point I'd start making fun of your username ;)
  - petercooper 14y ago
    It doesn't matter anyway. Semver is just a practice and not one everyone has or must sign up to, especially in its official form. Further, you're right about Ruby 1.9's hash syntax, although in the interests of accuracy, it's more accurate to consider it an additional syntax. It certainly doesn't replace the existing one (indeed, hashes notated in the new style get returned in the old style with #inspect) and I don't believe there are plans to ever remove the standard syntax.
  - tedunangst 14y ago
    Why would you expect PHP releases to adhere to rules that some guy threw together? Especially considering PHP has about a decade of history using the numbering scheme they do use.
- regularfry 14y ago
  Neither Ruby nor, as far as I know, PHP follow semver. Historically all bets have been off when it comes to breaking changes on "minor" releases.
- zem 14y ago
  are people really looking to this as a reason why php sucks? i thought the point of the post was to mock the "bug" reporter and his clueless sense of entitlement.
mparlane 14y ago
I am mostly on the side of the bug reporter here. PHP changed the behaviour of a simple method that has been there since PHP4 (which is oooold). It returned 0 previously for "", why change it now? Was "" == 0 a bug ?
- quink 14y ago
  A) The new behaviour makes more sense. B) The change was discovered as a difference in behaviour in two major releases that were three years apart. C) Rasmus Lerdorf can change PHP however he wants. It is precisely because of this that PHP has been so {'widely success', 'pain'}ful. D) The reporter was being overly dramatic regarding the change going to take a supposedly crazy amount of time to fix. E) You don't pass a string into a function that's usually returning a string without at least casting to a string when part of its intended behaviour is at times not returning a string. Casting in this case even before the function even changed would have been an exceedingly good idea. F) (edit) I vote we burn in hell PHP developers who tack on comments to a long closed bug report to offer their opinions like joezimjs did. Especially when they display a basic ignorance in saying crap like "NULL is neither a string nor a number."
  - mparlane 14y ago
    I work on systems where D) is perfectly reasonable. Where one "small" change results in a hell of a lot of regression testing and doc changes. What I don't get is that they are keen to modify php source. But not to just keep using the same php release? I agree with E, they take floats not strings apparently.
    - soulclap 14y ago
      Maybe there are other guidelines (Security related, no maintenance for the old release) that were 'forcing' them to update.
      - Evbn 14y ago
        I guarantee that security guidelines were not involved in any decision about which version of PHP to use in a project. All PHP code is security tainted and needs protection at the underlying data service layer.
gmedel 14y ago
To standardize PHP code is good, let's be clear... There's a lot of "misbehaves" in PHP. And if you're not casting or checking all the time you can get a wrong result, without even knowing. At least now/then (it's an old topic) number_format WILL tell you that you're not formatting a number and that's GOOD.
- ahi 14y ago
  To standardize PHP is to create a new language not named PHP.
  - phaus 14y ago
    If you read it until the end you will find out that the technical support representative talking to the irate customer is the creator of PHP. As the creator, PHP can be whatever he decides he wants it to be.
    - fffggg 14y ago
      And he has decided it is not a standardized language, by any stretch of the imagination. That's the guy's point, and it's spot-on. As an aside, I didn't realize there would be people on HN who wouldn't recognize rasmus@php.net immediately.
      - phaus 14y ago
        While there are some industry veterans here, there are also a good amount of CS students and other beginners. I myself didn't know who he was until I got to the end of the article.
    - jessedhillon 14y ago
      PHP can be whatever he decides he wants it to be What you're describing is whimsical, not standardized.
- TylerE 14y ago
  So what exactly is the point of PHP then? If you want to write Java, write Java. If PHP has any place in the world at all, it's as a language for the web with a minimum of extraneous boilerplate. If it fails at that goal, well, wtf? If you're going to be all proper about things, why not just do it in Python or some other sane language?
jconley 14y ago
Regardless of merit on either side, the attitude presented by the creator of PHP in this post makes PHP and open source in general look bad. Seriously? I still can't believe that's how the situation was handled. EDIT: Rasmus calls the bug reporter an idiot in the first reply. It's probably some sysadmin that has been tasked with upgrading the infrastructure and really has no idea what to do. So rude. It would take just as long to write: "Sorry about the inconvenience. We changed this undefined behavior for consistency's sake. You could cast the first argument to a float like: '[sample code]' and you'll get the old behavior back. One of our consulting partners [link] could help you with that if you'd like." Instead, Rasmus set the tone that he was superior from the onset.
- damian2000 14y ago
  To be honest, I think Rasmus shows some class in how he deals with the issue... others may have been far more abusive.
- Evbn 14y ago
  Why is one person working on one ancient project the face of open source?
  - stan_rogers 14y ago
    "One person" isn't. Rasmus isn't the only contributor to PHP, but it is his baby (originally released as his Personal Home Page Tools in the Long, Long Ago). That other people have worked on and contributed to PHP over the years doesn't change the fact that he's the creator of PHP.
- sunils34 14y ago
  Can you imagine how Linus would have handled it? I think Rasmus was fairly composed.
  - mpd 14y ago
    I'm honestly chuckling at the thought of Linus responding to this one in Rasmus' place. If you need the features of an old version, use the old version. Simple as that. Don't expect the rest of the world to be stuck with dealing with backward compatibility just so you aren't inconvenienced. Upgrade, pay for support, move to another platform, or stop complaining.
soulclap 14y ago
I understand that the bug reporter is in a bad situation but this is definitely an edge case and passing an empty or whatever non-numeric string to a function that is clearly meant for formatting numbers doesn't really seem like good style. is_numeric(), is_float() and casts are available for a reason. So I guess the answer is ultimately 'deal with it'. That said, I don't see this taking 'months' either, they could just write a wrapper function that mimics the old behaviour and their tests should cover it. If their quality control or inner workflows make changes like this take months, I'd expect that upgrading to a new PHP version and the related testing and QA should take them years.
- blantonl 14y ago
  this is a classic example of "you mess with the bull, you get the horns."
- reitzensteinm 14y ago
  A wrapper function is absolutely the right way. Instead, he decides to modify the PHP source and recompile it, effectively forcing him to maintain a fork of PHP, as if somehow that magically takes less effort to develop and QA resources to maintain. Wow.
  - blantonl 14y ago
    Spot on. He doesn't want to update his 50+ applications, but he wants to patch PHP and deal with the deployment of that to all the servers that support those 50+ applications. And he admits that he's not a C++ coder. Sounds like a change management nightmare.
    - lnguyen 14y ago
      But it's only one change.+ + Technically true. The scope will be equivalent to 50+ change tickets. And he'll be able to blame someone else for any issues that result.
  - mturmon 14y ago
    Just goes to show that the issue had become personal, not technical. The complainer was bent on showing Rasmus that his code was wrong (by implementing the change himself), not on fixing the problem in the easiest way.
damian2000 14y ago
Love this snippet: > > Please escalate this to someone who can answer the question as to why this was changed. -- endosquid at endosquid dot com > Escalate? Oh how I wish I had someone to escalate to. -- rasmus@php.net
- ranza 14y ago
  Gotta love Rasmus. He makes me proud to be danish :D
- thought_alarm 14y ago
  Rasmus comes across as a little kid. Here's how I read it: We have this public API that we're not exactly sure how it works version to version, and, oh, we've just changed our parsing code so if it breaks your stuff then tough shit because we're a bunch of amateurs. I especially liked this quote: "Wow, a classic case of how not to treat unpaid volunteers who provide critical pieces of your money-making infrastructure." Perhaps it isn't about being paid, but about taking pride in the work you do. PHP is convenient. I use it for some piddly shit because that's what it's good for. This bug report highlights the problems you run into if you use it for serious work.
  - pelotom 14y ago
    Don't get me wrong, PHP is a joke of a language, but I don't see Rasmus as the one behaving childishly here, and I also don't think he's in the wrong. APIs are allowed to change in major releases, and the behavior the plaintiff was relying on was so clearly broken it boggles the mind that he would riddle his code with dependencies on it.
    - masklinn 14y ago
      > APIs are allowed to change in major releases On the other hand, significant breakage of 10 years-old APIs with not even release notes...
      - gcb 14y ago
justindocanto 14y ago
"This is going to cause us MONTHS (to fix)". Whether he is right or wrong, you cannot say he's not over-exaggerating and being a pain in the ass. Also, expecting "" to == 0, when it's easier and proper to enter 0 just doesnt make sense. That's like saying "i expected your software to make up for me not using it correctly". Sass or not from the guy who wrote PHP, this guy is just a pain in the ass and his complaint is ridiculous. ADDITION: As the creator stated, it's been issuing warnings for some time now and was changed LAST YEAR. there's just no foundation to this complaint.
timtrinidad 14y ago
This reminds me of http://news.ycombinator.com/item?id=3860361 http://news.ycombinator.com/item?id=3860361. Ignoring something that needs to be fixed because it might break workarounds is a lot to expect, and it likely why the IEs stayed broken for so long.
Evbn 14y ago
Heh, if your steps to reproduce include redirecting error messages to /dev/null, it is hard to take your report seriously.
chavesn 14y ago
Having number_format in so many thousands of places across so many products is indicative of pretty poor code. If you have bad code, you can hardly expect to be able to upgrade to new versions of the language seamlessly. Speaking of which, are they going to upgrade to 5.3 without testing all those thousands of places across all their products?
- enjo 14y ago
  How is that indicative of bad code? That seems like a very big jump to make. If you're using PHP at the presentation layer you are probably doing a lot of this. Why would you write some sort of abstraction around number formatting when there is an abstract function to just do it for you? This is particularly true if your applications are older and written before modern template systems made it a bit easier to abstract these concepts to filters and the like.
  - chavesn 14y ago
    I'm just saying it's a sign, or a smell. Just as you say older/pre-modern -- bad code or not, the same caveat applies about upgrading core language platforms. Even a strictly typed language with a much more standardized API like Java can be hard to upgrade major versions (where I would consider 5.3 a new major version).
- arde 14y ago
  It's bad code alright. But I would argue that any code you write in a bad language turns into bad code, no matter how you do it. It might be good enough for your application, so that's fine. But it would be bad nonetheless. And PHP is not a sane language by any measure. So here we have a bad code author dealing with it's bad languague's shortcomings and expecting that they be solved by the very people who created said bad language in the first place. Quite entertaining.
Evbn 14y ago
Wait, endosquid writes tax software and expects that whenever a bit of data gets corrupted it should display an account balance of 0? Please share the name of this phenomenal software product.
- SomeCallMeTim 14y ago
  I got stuck on "endosquid writes critical tax reporting software in PHP?!", actually.
  - alkavan 14y ago
    Yup, indeed this is the main problem here. I work with PHP for many years, but i would not suggest using PHP layer as core of my "Taxing software", PHP is not statically typed means it's not suited well for this job, in e-commerce sites i built in past there were always problems when it gets to tax calculations, you learn to deal with it by wrapping your calculation code in the right way and testing it currently. It is probably the case when unskilled programmers just used number_format() directly instead of wrapping it with "Tax" class that does that you want it to do, and nothing else. it was indeed common in PHP 4, but we have moved since then.
  - StavrosK 14y ago
    alkavan's comment on this thread is dead, reposted here: Yup, indeed this is the main problem here. I work with PHP for many years, but i would not suggest using PHP layer as core of my "Taxing software", PHP is not statically typed means it's not suited well for this job, in e-commerce sites i built in past there were always problems when it gets to tax calculations, you learn to deal with it by wrapping your calculation code in the right way and testing it currently. It is probably the case when unskilled programmers just used number_format() directly instead of wrapping it with "Tax" class that does that you want it to do, and nothing else. it was indeed common in PHP 4, but we have moved since then.
- Yver 14y ago
  Indeed, it's amazing that the same person could say "We are passing a (possibly uninitialized, or null-valued) variable to the function, in hundreds of places and web pages" and "Each of those changes will have to be coded, tested, written-off, released, tested by the clients since this is tax data and has to be precise for tax planning and retirement planning." They are very thorough with testing their super-important tax software. Well, except they ignore uninitialized variables, but I hear those are A-OK in accounting.
josephcooney 14y ago
Way to jump onto a thread that hadn't had any comments in 10-month-old joezimjs and add pretty much zero to the conversation.
fink0136 14y ago
This makes me so excited to be a budding Perl dev.
josephcooney 14y ago
The "is there anyone you can escalate this too" reminds me of a PERL newsgroup thread I saw where someone tried to rip Larry Wall a new one, asking (in a condescending way) him if he knew anything about PERL.
- Xcelerate 14y ago
  Haha, if you could find that again I'd like to see it!
- aidenn0 14y ago
  Or the time I suggested on HN that cperciva use scrypt (not noticing the username on the comment).
pippy 14y ago
So developers complain that PHP is not standardised, but when it is in a major version upgrade developers complain that it's becoming standardised?
- icebraining 14y ago
  Are you somehow under the impression that developers are the Borg? Different developers can have different opinions on what PHP should be.
- RobAley 14y ago
  A lot of the time, it's developers who don't use PHP who complain its not standardised, and developers who do use PHP who complain when it does change! To be contrary, I'm a PHP developer who likes the on-going standardisation, but didn't really find it too big a problem the existing way. YMMV.
soulclap 14y ago
Related article about the same bug report: "When does a bug turn into a feature?" http://lwn.net/Articles/369505/ http://lwn.net/Articles/369505/
moot 14y ago
> After carefully reviewing this bug report with our board of directors on 4chan, we have come to the conclusion that your "rusty C skills" should be enough to fix the issue. I am sad I was not invited :(
- jsilence 14y ago
  You should escalate that up at 4Chan!
- deleted 14y ago
  [deleted]
kevinalexbrown 14y ago
Leaving aside the irony of asking Rasmus to escalate the issue (this would be like complaining in an "Ask HN:" and suggesting that pg escalate the issue up the ycombinator chain), or whether the change was logical or not, I learned something cool from one aspect of Rasmus' response: ... there are many many people out there affected by these changes, we recognize that. That is also why we are not likely to reverse a change like this that others in your situation have now accounted for, tested and deployed in production for many months ... -- rasmus. Good decisions don't always mean everyone goes home happy. Whether or not the change was good or bad, reversing it now could negatively impact anyone else who already adjusted. If it means "MONTHS" of work for this guy, in order to save "MONTHS" of work for 100 others who use PHP, so be it. Even if we were to take a leap of faith and assume it was a bad decision by Rasmus to make the change in the first place, it's been done. Responding to inconsistency with more changes seems like trying to regain your balance by making wilder and wilder swings of your arms.
- gcb 14y ago
  if you can't do that trivial change on some convulated release system... You don't change php version either. Unless you are addressing security changes. I think its very professional to not bump versions just for the sake of it. release notes exist for a reason.
  - webreac 14y ago
    As far as I understood, the release notes were not very explicit or complete (the list of impacted functions were missing) on this issue. Recently I have encountered a problem with redhat migration: /usr/bin/X11/xwd was "moved" to /usr/bin/xwd. I have not found anything in the release note. It is not enough to ask people to read the release notes, these release notes should be complete and usable.
    - TillE 14y ago
      The point is that the release notes will tell you if there are security flaws fixed. There's no substitute for actually testing your code with a new environment before deploying it.
TwoBit 14y ago
In most mature programming languages we resolve this kind of dispute by pointing to the Standard. Is that not possible with PHP?
- johnny22 14y ago
  Well that's what happened to this guy. He relied on unstandard/undefined behaviour and when php switched to a standard parameter parser it broke his app.
jister 14y ago
In this kind of situation where there's a bug or limitation or some kind of issue with a language function we usually create a wrapper to handle the whatever rules we have internally within the company. In this case the empty string that is supposed to be NULL should be handled within that wrapper function. One function to modify instead of several places in the application.
kyberias 14y ago
People have been wondering "what would Linus have said?" I'm pretty sure he wouldn't have broken the existing (undocumented) behavior in the first place "because it breaks applications and the one and only reason for kernel is to allow applications to run". But then again, PHP is not a kernel. :)
- aniket_ray 14y ago
  I think you are entirely right. As Linux says "Kernel exists for its users". Pretty similarly, a platform (php/zend) exists for its applications. Linus has always been pretty adamant about not breaking API behaviour even undocumented ones. But in this case, undefined behaviour had been previously documented. Also, was it him or Ulrich Drepper who were against changing memcpy undocumented behaviour. (mempcy used to work with overlapping regions too.) PS. This mailing thread is from 2010. It's really old.
  - lmm 14y ago
    Ulrich Drepper was vigorously in favour of it. If your application breaks, it's because it was written wrong.
    - Draiken 14y ago
      Exactly. The only reason this bug got to production, is because the function accepted an empty string parameter in the first place.
  - fragmede 14y ago
    Yes, eg: https://lwn.net/Articles/494993/ https://lwn.net/Articles/494993/ Linus took extra steps to no break autofs behavior, even though it was (more) due to a bug in GCC than anything else.
chris_wot 14y ago
Uh, so let me get this straight. They are using number_format, which according to the documentation takes a number and formats as a string, and giving it a string as the input parameter? They were never using the function correctly in the first place! Not sure what they have to complain about here...
rahul342 14y ago
Shouldn't it be raising an exception instead of returning NULL or 0 for ""?!
kenneth 14y ago
There are countless reasons to bash on PHP because, frankly, it is a pretty terrible language[1]. However, this is not a valid reason. The bug reporter is being idiotic and needlessly disrespectful, and is making a big deal out of something that can be easily fixed with a simple `sed` command, as Rasmus demonstrated. And, to be honest, he is clearly demonstrating the fact that he's a pretty poor developer, and that he doesn't have the necessary qualifications to be writing software that manages people's retirement funds. Also, when dealing with something as important as that, you ought to know better than to base our technology on top of PHP. [1]: Coming from somebody who built a very successful startup on top of PHP.
- SjuulJanssen 14y ago
  "Also, when dealing with something as important as that, you ought to know better than to base our technology on top of PHP." Upon reading the conversation I was amazed he didn't get that response right away.
- rbanffy 14y ago
  What shocks me most is the sense of entitlement. They downloaded PHP, its behavior changes and they'd rather complain to those who changed it and annoy them until the thing works for them again than fix the bug in their code. If they are not happy with the free product and the free support, there are other options. PHP has its shortcomings, but, as in any open source product, if it doesn't work for you, you have a couple options.
  - jiggy2011 14y ago
    Problem is, at that point you have built a lot of business on top of it. So the issue of whether or not it is "free" is moot because it has a very real dollar value to you and also probably to the boss who is breathing down your neck.
    - rbanffy 14y ago
      Then they have a couple options: fork and keep their own fork, they can pay the PHP community (or someone in it) to change it back (or to provide a backwards-compatibility mechanism) or pay developers to change their software to work with newer versions of PHP. They can't bully their way like they tried.
Groxx 14y ago
So the options are: 1. Change thousands of lines of code (probably `sed`-able) 2. Patch PHP to re-introduce the original bug/feature 3. Downgrade PHP back to the version that had the bug/feature you were relying on Why is option 3 not considered in this thread? It was working before, and evidently they can control the version of PHP (since they can patch it). If upgrade breaks X, and you rely on X, don't upgrade. If you need to upgrade for Y, do so, and fix X. That's just how such things work.
- sold 14y ago
  Problem 1: The old versions do not get security patches. For example, entering the number 2.2250738585072011e-308 hangs the interpreter in old versions, as far as I know this is unpatched in PHP <=5.1. This allows a very effective denial of service. Problem 2: You are delaying the unevitable; it's nice to use new features of the language, having to code in old versions is a pain for developers. Small continuous upgrades are easier to handle than rare gigantic ones.
  - Groxx 14y ago
    Small continuous upgrades without ever changing your code is the same cost as a gigantic one without ever changing your code - they either work, or they don't, in variously subtle or spectacular ways. The tipping point lies at some changeset, you just need to hit it. You upgrade, you may need to change things. It's just a fact of life. Or, you pick a library / language / framework / everything that guarantees 100% backwards compatibility as documented, that never has bugs (since fixing those breaks 100% backwards compatibility), and you never use features in even remotely-unexpected ways. Like in this case.
    - Kabacaru 14y ago
      This is why having a good suite of unit tests is so important.
- wccrawford 14y ago
  3) He said they changed hosts and very few hosts offer old versions of PHP. I don't know if that's correct, but that's what was used as an excuse.
10098 14y ago
Ah, the joys of dynamic typing.
- andreasvc 14y ago
  No, this is about _weak_ typing (as opposed to strong typing). Static vs. dynamic is another matter.
robryan 14y ago
You can't win, people on one side want this weird behaviour made backwards compatible whereas people complain that the language has a large amount of weird edge cases and should be better standardised around more sane expected values. In this case they were standardising parameter parsing code, which I think is definitely the direction you want to head.
billpg 14y ago
PHP is doing the right thing here. Way back when I first tried PHP out, I tried joining strngs together with a + operator. I made a mistake, but I kept getting back zeros instead of some sort of NULL or an exception. This is a bug, in the sense of its not how I wanted PHP to behave. I'm glad PHP is fixing its string-to-numeric bugs.
olleicua 14y ago
Here's to not using PHP for anything serious! The whole point of a dynamically typed language is that arguments could be of any type. Language built-ins should account for this. Of course PHP doesn't and shouldn't be expected to. The fact that Facebook, MediaWiki, and WordPress are so successful is still a mystery to me.
- ceejayoz 14y ago
  > The fact that Facebook, MediaWiki, and WordPress are so successful is still a mystery to me. The fact that some developers think the language chosen has much effect on the success of a site is still a mystery to me.
buster 14y ago
All the discussion aside, there is so much wrong with it: First of all, why does the function even accept strings? There should be some eception happening. Second, why does it return 0, i could understand NULL but not 0 (for a function that is supposed to handle numbers, having it return a number in the invalid case, what is that?)
- RobAley 14y ago
  PHP is a dynamically typed language, so although it expects a number, it will accept a string as it will try and parse that string into a number (e.g. you could pass it the string "2.23232" and it will work in the same way as if you pass it 2.23232 as a float). In this particular case, as the empty string can't be parsed into a number, it does indeed throw a PHP warning and treats it as a null input. My understanding is that it used to return 0 and that was considered a bug by some (although others, including the author of the function, decided that as the return type was a number it should ALWAYS return a number). The change that is under "dispute" in this case is that it has indeed been changed to return null, which is what most people now agree is the best way, and is consistent with other PHP functions.
  - jablan 14y ago
    I believe you are refering to strongly vs weakly typed, not statically vs dynamically typed. A strongly typed language would not try to parse the string into a number (although it would indeed accept a string, if it is dynamically typed as well).
    - RobAley 14y ago
      I did indeed mean weakly typed (PHP is both dynamically and weakly typed). Haven't had my coffee yet this morning.
- masklinn 14y ago
  > First of all, why does the function even accept strings? Why not? > There should be some eception happening. PHP's built-in functions do not ever throw exceptions. > Second, why does it return 0, i could understand NULL but not 0 Well it doesn't anymore, but it used to, and that kind-of made sense in the context of the language being PHP: in PHP (userland), when using a string in a numeric context that string will automatically be converted to a number: > php -r 'print (1 + "3") . "\n";' 4 when the string can not be parsed to a number (meaning it is not prefixed by something which looks like a number), it's just converted to `0`: > php -r 'print (1 + "whelp") . "\n";' 1 And I expect that is the former behavior of the function: it coerced whatever it got to a number, so an empty or non-numeric string would get converted to the float 0.0, which would then get formatted as usual.
wanderr 14y ago
I have to agree with the bug submitter in concept, if not in attitude. PHP is a dynamically typed language. As such, methods should expect surprises about the types of data received. Seriously, I've had PHP treat the same input as a string one time, an interface another, it's like it uses whatever is convenient at the time. If you neeeeed that data to be an int, cast it as an int, don't punish the user because type system chose a different type this time. Additionally, and more to the point, in PHP 0 == "" == null == false, so it shouldn't be unreasonable to expect them to be treated as equivalent. It's also a nice thing when a method can always be trusted to return the same type, or these types of issues can end up cascading. In any case, 'should' and 'nice' things are hard to rely on in PHP, that's why you should always have the docs open and read everything when writing PHP, making even basic assumptions about a method being well behaved will likely screw you over. :)
- Terretta 14y ago
  Especially for a novice, formatting a field on a web form into a number, and seeing PHP format an empty field as zero, so you can carry on with your math, makes sense. "Oh, web parsing language, sees empty number field as zero, great!" Principle of least surprise "for the novice web developer" says empty string to zero makes sense in this case. Meanwhile, empty string with zero decimal places returning null would be less surprising to a pro, but in PHP, the first behavior would also be unsurprising to a pro.
sneak 14y ago
In April 2010 Rasmus Lerdorf joined WePay (a YC startup) in a senior position. http://techcrunch.com/2010/04/27/php-founder-rasmus-lerdorf-joins-group-payments-startup-wepay/ http://techcrunch.com/2010/04/27/php-founder-rasmus-lerdorf-... He's always been like this, best I can tell.
deepGem 14y ago
"Please escalate this to someone who can answer the question as to why this was changed. If no one knows, then why was default behavior changed?" Mr.Rasmus, respect, for not ending the thread at this statement.
robryan 14y ago
In the same way that projects enforce a certain subsection of c++, it is probably best in PHP to not code anything in a way that relies on unusual quirks of the language to work. None of my code gets bitten here because I never passed number_format anything but numbers.
- andreasvc 14y ago
  In my opinion weak typing is an unusual quirk, but there's no way to get around that. I really wonder kind of reasons could be given to defend it; I don't think a strongly typed language like Python is any harder because of its types.
  - robryan 14y ago
    I tend to agree, these days where possible when working in PHP I try not to rely on PHPs magic type conversions behind the scenes for things like comparisons.
    - andreasvc 14y ago
      You can't really avoid weak typing; e.g., making a mistake in a strongly typed language would raise an error, whereas in a weakly typed language it can silently screw up everything.
methodin 14y ago
Blaming your problems on the person making something you are consuming is always a useless endeavor. Make a function if you are using something in hundreds of places that relies on user input. Not terribly difficult.
ndrw 14y ago
The documentation is right and the "engineers" are wrong! And it's also a good example why you should stay away from using undocumented stuff. If the documentation says "float $number" you best better give it a float, dammit! Engineers, my a$$...
snorkel 14y ago
Headline of this post is totally false and this is not even a bug in PHP, it's clearly a bug in the poster's code, so Rasmus response is right. If you actually try doing this in PHP you get this: print number_format("",0); Warning: number_format() expects parameter 1 to be double, string given in Command line code on line 1 So the poster willfully ignored the warning. You can fix this simply by casting the first arg as a numeric type: print number_format((int)"",0); 0 Please, if you're this bad at programming and you willfully ignore warnings, don't file bugs, and please do not take a programming job at some place that does important things like air traffic control, banking, or life support systems.
- DHowett 14y ago
  The headline of this post is such because it is quoting a PHP developer on a point made in a later comment on the report.
  - xd 14y ago
    The quote was tongue in cheek.
- psaintla 14y ago
  I think there are two bigger issues: 1.) Things like this should not be warnings in the first place. There should be more strict handling of invalid input so they result in actual exceptions being thrown instead of output that can be exploited in incorrect/undocumented ways. 2.) The php.net documentation for number_format doesn't even state that NULL is a possible output value. And I can't find anything in the changelogs stating when this change was made (admittedly I glanced quickly so I may have missed it) You state that it is a bug in PHP, but I respectfully disagree. This is a bug in the varied way in which PHP returns output based on invalid input. Some functions return 0, some functions return NULL, some functions return FALSE and it seems as if it is all done arbitrarily. This really should end, invalid input should result in standard exceptions being thrown so they can be handled.
  - wpietri 14y ago
lnanek2 14y ago
This is pretty standard with large production software. You often see grids in the documentation, e.g. this version of the app server is only certified for these brands and versions of Java. Even if you have a paid support contract with us, do not contact us re using it on something else. So in the reporter's case, their software just isn't certified for the new version until updated. No big deal. I remember working at a company where the servers were Ubuntu, the auto-update mechanism replaced Sun Java with OpenJDK which broke countless apps and web servers, like the Concur app, the build system, etc.. God that was a nightmare. A real setup like at bigger companies I've worked at would have tested that update on developer boxes, integration boxes, testing and training boxes, and only then sent it to production.
gedrap 14y ago
It was really to read that conversation. I do not care whether it was a good or bad decision to make those changes in PHP but you simply can not talk like that to a person who has put thousands of hours of unpaid work (while he could get a fat pay check easily) and you are making living because of what he has done. It's just immature.
Darkstar 14y ago
Everybody was in the wrong here. The developer should've written better code. I'm a PHP developer and I've learned that if the input is that important, I need to cast it. I've used C++, C#, and Java and I like strict typing. If your application is that sensitive then maybe it should've casted the input to ensure the output is consistent. As for Rasmus, I think he could've explained why it's a "won't fix" type bug in a slightly more diplomatic fashion, though I can't say I would've handled it any differently. He's completely right as to why the behavior shouldn't change. Finally, bjori's response was completely unnecessary, inflammatory, and downright rude. This has shown me the worst of the PHP community. I'm not ashamed, just more wary.
- ericingram 14y ago
  This is exactly how I feel about it. I think it's an example of how not to interact in a community, from both angles. Also, I can't stand the notion that open source developers are "volunteering" their effort. All programming is voluntary in the sense that you are making a free choice to do it and most likely gaining capital (social or financial) in the process. I voluntarily build software and give or sell it to others all the time.
ivanhoe 14y ago
Issue here is not whether it can be fixed, anything can be fixed. Issue here is why in the world they have changed things in a such way to break the old code?! Was it necessary? I don't think so... I understand the need to re-factor, and making some old stuff obsolete along the way, of course, but it's not the case here. It's just that someone wasn't really playing attention to this. And this type of negligence to the details is really killing php as language. If after 10+ years in php I need to re-read the manual every now and then to make sure if the things are still working like the last time, it's just crazy..
Killswitch 14y ago
| ^ 0 isn't some magic all-encompassing number. It means 0. NULL means no number based on your shitty incorrect input, and is the correct choice. Best response to the whole thing except for Rasmus' awesomeness.
strictfp 14y ago
Stop doing automagical conversions and all these problems will go away.
prisonguard 14y ago
a pal of mine recently upgraded a big corp's pcs from win xp to win 7 . the long wait was due to excel macros which could not run in the latter os. they couldnt switch even after him rewriting and testing them to run. [edit] typo
peterkelly 14y ago
... and that's why you don't use PHP.
deleted 14y ago
[deleted]
- pbiggar 14y ago
  I've flagged your comment. Please remove it. Just because we observe somebody being a dick on the internet, does not give us permission to stalk them, expose their personal information (even if it can be freely found on the internet), round up a lynch mob, etc. This is very bad behaviour on your part. This sort of thing can ruin lives. Please take it down.
  - deleted 14y ago
    [deleted]
    - StefanKarpinski 14y ago
      I'm happy to remove the comment. What guideline is this in direct opposition to? Genuine question, not being snarky.
      - pbiggar 14y ago
        Its in the footer: http://ycombinator.com/newsguidelines.html http://ycombinator.com/newsguidelines.html
        StefanKarpinski 14y ago
        "Be civil."?
        pbiggar 14y ago
        Probably also "Don't say things you wouldn't say in a face to face conversation." (at least, I hope so)
      - deleted 14y ago
        [deleted]
loup-vaillant 14y ago
> Find the dependencies —and eliminate them Excel team motto.[1] While I understand Rasmus' response is legitimate, I also see that depending on something as crucial as a programming language implementation is less of a good idea than it might seem at first. Makes things like Maru (the programming language[2], not the cat) much more appealing: if there's something you don't like in your compiler, at least you stand a chance at fixing it (Maru is less than 2K lines, and counting down). [1]: http://www.joelonsoftware.com/articles/fog0000000007.html http://www.joelonsoftware.com/articles/fog0000000007.html [2]: http://piumarta.com/software/maru/ http://piumarta.com/software/maru/
deleted 14y ago
[deleted]
cldrope 14y ago
I think the guy wasn't thinking the situation through entirely, but someone of (relative respect I suppose, creator of PHP is still the creator of something widely used) respect shouldn't be acting like this. It's always a shame to see people who have promise and talent show how childish they CAN act. Having his underling (someone who works on his language of no known note) make a smartassed response was in turn also pointless and negative whether he requested/urged it passively or not.
FuzzyDunlop 14y ago
> Each of those changes will have to be coded, tested, written-off, released, tested by the clients since this is tax data and has to be precise for tax planning and retirement planning. Considering the filer of the report goes on to say this, at what point did they fail to realise that moving from an "old PHP 5.1.6 Solaris 8 box" to an "RHEL5 with 5.3.1" should have required the same level of testing and signing off? No sympathy for a developer who completely changes their environment (OS, PHP version, at the very least) and then bitches about stuff they failed to anticipate not working. This is not a reflection on PHP, for once.

382 points by robbiet480 14y ago

Upvoting, because the issue at hand is so old that I find it funny people will use this as a reason as to why "PHP sucks". For the record, the version in question was 5.3.1 vs 5.1.6, two releases away and three years apart. Of course you'll need to test updates to your app with such version changes. Yes, using semver means this is a minor version release, but if we do that, I'll be first to note the lovely hash syntax changes in Ruby 1.9. In any case, the current release is 5.4.4.

rurounijones 14y ago
Sorry I couldn't grok what your opinion on semver was. Ruby 1.9 introduced new hash syntax but did NOT break the existing syntax one so it was a minor version release (backwards compatible). PHP made an backwards incompatible change in their code so it should have been a major version increase. So as far as I can see Ruby is in the right and PHP is in the wrong with regards to adhering to semver. Is that not your opinion?
- deleted 14y ago
  [deleted]
- josegonzalez 14y ago
  The following does not work anymore in 1.9 (at least when it was released, who knows if they reverted the change): {"a", "b"} And there were plenty of gems and small scripts online I was able to get working just fine under 1.8.7 but not 1.9. Thankfully that is largely no longer the case, as things have been updated or replaced. String class was also given a nice kick in the ass, at least in regards to iteration. Would you say that these were not backwards incompatible changes? Code that worked before stopped working. Breaks BC in my book. And in both cases the changes were arguably for the better. - Stop writing code with uninitialized variables - Stop iterating over stuff that shouldn't be iterated over in that way As far as why the changes were thus, it was decided to destroy PHP 6 - do people still write books about that? - and port every change other than unicode support down to 5.x. Someone feel free to correct me on that point.
  - petercooper 14y ago
    It doesn't work in the latest 1.9 either. It was a bizarre syntax that hardly anyone used from my experience (I've been a library-oriented Rubyist for several years and never saw it in production code.) However, String is a good point, and especially around character encodings. Not to mention threads, major stdlib changes, enumerators, and more..
  - piggity 14y ago
    I don't "really mind" if it breaks totally (i.e. throws an appropriate exception or doesn't parse the syntax check). I find it much more irritating when the behaviour subtly changes and introduces edge cases that may not be picked up in testing / normal usage.
    - josegonzalez 14y ago
      Passing in an empty string to a function that states it takes float as it's argument is certainly an edge case the developer should have thought of.
      - masklinn 14y ago
        The again, in PHP, interpreting strings as floats is not unusual and pretty well defined. So in PHP it's also a case the developer could have considered normal in his expectation that PHP would behave as usual (and it did, prior to 5.3, for this precise function)
        methodin 14y ago
        Not for user-provided input. That's just a dumb thing to do in any language.
        masklinn 14y ago
        > Not for user-provided input. Not what for user-provided input? The source of a string does not matter to this rule of PHP: a string used in numeric context will be parsed and converted, if it can not be parsed as a number its numeric value will be 0. That's it. That's how the language defines strings in numeric contexts. > That's just a dumb thing to do in any language. Sure, you won't get any argument from me on that, but that remains how PHP works and has always worked.
- gurkendoktor 14y ago
  Somewhere around Ruby 1.8.6, the stdlib Digest::MD5 syntax changed without any explanation that I know. In one patchlevel of 1.8.6, they've added a check against creating new Ruby objects while the GC is running (I hope I remember this right), breaking all SWIG extensions at once. Ruby 1.8.7 changed the C extension API, I think? I'm not sure if 1.8.7 broke the old one or if 1.9 did. Ruby 1.9 broke "when 5:" in case statements. Files also started needing "# Coding: UTF-8" comments. And then there are subtle changes that probably aren't even documented, like [Math.sin 0] not being valid syntax anymore. Block variable scoping and automatic splitting into Arrays is different. Ruby 1.9.2 (!) changed the way require() works and added require_relative() which is impossible to properly backport. And Ruby 1.9.3 fixed a parser bug again, breaking code that worked on 1.9.2. (I think you could have a superfluous "do" in one place.) Those are the breaking changes that I can remember from first-hand experience now, only the last one is second-hand over IRC. And this is excluding Rake, Rubygems and all the other crap that breaks at every other git commit. Ruby is a bad example.
  - josegonzalez 14y ago
    I used it as the example simply because it is normally a language that is touted quite superior to PHP. I think it is better in some regards - building/using Ruby DSLs is awesome - but not all. Languages are subject to bugs. If they didn't have bugs, people wouldn't complain.
    - iamumassthrower 14y ago
      Hahaha. People wouldn't complain. That's a knee slapper.
      - sirclueless 14y ago
        No more preposterous than software without bugs.
      - josegonzalez 14y ago
        At that point I'd start making fun of your username ;)
- petercooper 14y ago
  It doesn't matter anyway. Semver is just a practice and not one everyone has or must sign up to, especially in its official form. Further, you're right about Ruby 1.9's hash syntax, although in the interests of accuracy, it's more accurate to consider it an additional syntax. It certainly doesn't replace the existing one (indeed, hashes notated in the new style get returned in the old style with #inspect) and I don't believe there are plans to ever remove the standard syntax.
- tedunangst 14y ago
  Why would you expect PHP releases to adhere to rules that some guy threw together? Especially considering PHP has about a decade of history using the numbering scheme they do use.
regularfry 14y ago
Neither Ruby nor, as far as I know, PHP follow semver. Historically all bets have been off when it comes to breaking changes on "minor" releases.
zem 14y ago
are people really looking to this as a reason why php sucks? i thought the point of the post was to mock the "bug" reporter and his clueless sense of entitlement.

mparlane 14y ago

I am mostly on the side of the bug reporter here. PHP changed the behaviour of a simple method that has been there since PHP4 (which is oooold). It returned 0 previously for "", why change it now? Was "" == 0 a bug ?

quink 14y ago
A) The new behaviour makes more sense. B) The change was discovered as a difference in behaviour in two major releases that were three years apart. C) Rasmus Lerdorf can change PHP however he wants. It is precisely because of this that PHP has been so {'widely success', 'pain'}ful. D) The reporter was being overly dramatic regarding the change going to take a supposedly crazy amount of time to fix. E) You don't pass a string into a function that's usually returning a string without at least casting to a string when part of its intended behaviour is at times not returning a string. Casting in this case even before the function even changed would have been an exceedingly good idea. F) (edit) I vote we burn in hell PHP developers who tack on comments to a long closed bug report to offer their opinions like joezimjs did. Especially when they display a basic ignorance in saying crap like "NULL is neither a string nor a number."
- mparlane 14y ago
  I work on systems where D) is perfectly reasonable. Where one "small" change results in a hell of a lot of regression testing and doc changes. What I don't get is that they are keen to modify php source. But not to just keep using the same php release? I agree with E, they take floats not strings apparently.
  - soulclap 14y ago
    Maybe there are other guidelines (Security related, no maintenance for the old release) that were 'forcing' them to update.
    - Evbn 14y ago
      I guarantee that security guidelines were not involved in any decision about which version of PHP to use in a project. All PHP code is security tainted and needs protection at the underlying data service layer.

gmedel 14y ago

To standardize PHP code is good, let's be clear... There's a lot of "misbehaves" in PHP. And if you're not casting or checking all the time you can get a wrong result, without even knowing. At least now/then (it's an old topic) number_format WILL tell you that you're not formatting a number and that's GOOD.

ahi 14y ago
To standardize PHP is to create a new language not named PHP.
- phaus 14y ago
  If you read it until the end you will find out that the technical support representative talking to the irate customer is the creator of PHP. As the creator, PHP can be whatever he decides he wants it to be.
  - fffggg 14y ago
    And he has decided it is not a standardized language, by any stretch of the imagination. That's the guy's point, and it's spot-on. As an aside, I didn't realize there would be people on HN who wouldn't recognize rasmus@php.net immediately.
    - phaus 14y ago
      While there are some industry veterans here, there are also a good amount of CS students and other beginners. I myself didn't know who he was until I got to the end of the article.
  - jessedhillon 14y ago
    PHP can be whatever he decides he wants it to be What you're describing is whimsical, not standardized.
TylerE 14y ago
So what exactly is the point of PHP then? If you want to write Java, write Java. If PHP has any place in the world at all, it's as a language for the web with a minimum of extraneous boilerplate. If it fails at that goal, well, wtf? If you're going to be all proper about things, why not just do it in Python or some other sane language?

jconley 14y ago

Regardless of merit on either side, the attitude presented by the creator of PHP in this post makes PHP and open source in general look bad. Seriously? I still can't believe that's how the situation was handled. EDIT: Rasmus calls the bug reporter an idiot in the first reply. It's probably some sysadmin that has been tasked with upgrading the infrastructure and really has no idea what to do. So rude. It would take just as long to write: "Sorry about the inconvenience. We changed this undefined behavior for consistency's sake. You could cast the first argument to a float like: '[sample code]' and you'll get the old behavior back. One of our consulting partners [link] could help you with that if you'd like." Instead, Rasmus set the tone that he was superior from the onset.

damian2000 14y ago
To be honest, I think Rasmus shows some class in how he deals with the issue... others may have been far more abusive.
Evbn 14y ago
Why is one person working on one ancient project the face of open source?
- stan_rogers 14y ago
  "One person" isn't. Rasmus isn't the only contributor to PHP, but it is his baby (originally released as his Personal Home Page Tools in the Long, Long Ago). That other people have worked on and contributed to PHP over the years doesn't change the fact that he's the creator of PHP.
sunils34 14y ago
Can you imagine how Linus would have handled it? I think Rasmus was fairly composed.
- mpd 14y ago
  I'm honestly chuckling at the thought of Linus responding to this one in Rasmus' place. If you need the features of an old version, use the old version. Simple as that. Don't expect the rest of the world to be stuck with dealing with backward compatibility just so you aren't inconvenienced. Upgrade, pay for support, move to another platform, or stop complaining.

soulclap 14y ago

I understand that the bug reporter is in a bad situation but this is definitely an edge case and passing an empty or whatever non-numeric string to a function that is clearly meant for formatting numbers doesn't really seem like good style. is_numeric(), is_float() and casts are available for a reason. So I guess the answer is ultimately 'deal with it'. That said, I don't see this taking 'months' either, they could just write a wrapper function that mimics the old behaviour and their tests should cover it. If their quality control or inner workflows make changes like this take months, I'd expect that upgrading to a new PHP version and the related testing and QA should take them years.

blantonl 14y ago
this is a classic example of "you mess with the bull, you get the horns."
reitzensteinm 14y ago
A wrapper function is absolutely the right way. Instead, he decides to modify the PHP source and recompile it, effectively forcing him to maintain a fork of PHP, as if somehow that magically takes less effort to develop and QA resources to maintain. Wow.
- blantonl 14y ago
  Spot on. He doesn't want to update his 50+ applications, but he wants to patch PHP and deal with the deployment of that to all the servers that support those 50+ applications. And he admits that he's not a C++ coder. Sounds like a change management nightmare.
  - lnguyen 14y ago
    But it's only one change.+ + Technically true. The scope will be equivalent to 50+ change tickets. And he'll be able to blame someone else for any issues that result.
- mturmon 14y ago
  Just goes to show that the issue had become personal, not technical. The complainer was bent on showing Rasmus that his code was wrong (by implementing the change himself), not on fixing the problem in the easiest way.

damian2000 14y ago

Love this snippet: > > Please escalate this to someone who can answer the question as to why this was changed. -- endosquid at endosquid dot com > Escalate? Oh how I wish I had someone to escalate to. -- rasmus@php.net

ranza 14y ago
Gotta love Rasmus. He makes me proud to be danish :D
thought_alarm 14y ago
Rasmus comes across as a little kid. Here's how I read it: We have this public API that we're not exactly sure how it works version to version, and, oh, we've just changed our parsing code so if it breaks your stuff then tough shit because we're a bunch of amateurs. I especially liked this quote: "Wow, a classic case of how not to treat unpaid volunteers who provide critical pieces of your money-making infrastructure." Perhaps it isn't about being paid, but about taking pride in the work you do. PHP is convenient. I use it for some piddly shit because that's what it's good for. This bug report highlights the problems you run into if you use it for serious work.
- pelotom 14y ago
  Don't get me wrong, PHP is a joke of a language, but I don't see Rasmus as the one behaving childishly here, and I also don't think he's in the wrong. APIs are allowed to change in major releases, and the behavior the plaintiff was relying on was so clearly broken it boggles the mind that he would riddle his code with dependencies on it.
  - masklinn 14y ago
    > APIs are allowed to change in major releases On the other hand, significant breakage of 10 years-old APIs with not even release notes...
    - gcb 14y ago

justindocanto 14y ago

"This is going to cause us MONTHS (to fix)". Whether he is right or wrong, you cannot say he's not over-exaggerating and being a pain in the ass. Also, expecting "" to == 0, when it's easier and proper to enter 0 just doesnt make sense. That's like saying "i expected your software to make up for me not using it correctly". Sass or not from the guy who wrote PHP, this guy is just a pain in the ass and his complaint is ridiculous. ADDITION: As the creator stated, it's been issuing warnings for some time now and was changed LAST YEAR. there's just no foundation to this complaint.

timtrinidad 14y ago

This reminds me of http://news.ycombinator.com/item?id=3860361 http://news.ycombinator.com/item?id=3860361. Ignoring something that needs to be fixed because it might break workarounds is a lot to expect, and it likely why the IEs stayed broken for so long.

Evbn 14y ago

Heh, if your steps to reproduce include redirecting error messages to /dev/null, it is hard to take your report seriously.

chavesn 14y ago

Having number_format in so many thousands of places across so many products is indicative of pretty poor code. If you have bad code, you can hardly expect to be able to upgrade to new versions of the language seamlessly. Speaking of which, are they going to upgrade to 5.3 without testing all those thousands of places across all their products?

enjo 14y ago
How is that indicative of bad code? That seems like a very big jump to make. If you're using PHP at the presentation layer you are probably doing a lot of this. Why would you write some sort of abstraction around number formatting when there is an abstract function to just do it for you? This is particularly true if your applications are older and written before modern template systems made it a bit easier to abstract these concepts to filters and the like.
- chavesn 14y ago
  I'm just saying it's a sign, or a smell. Just as you say older/pre-modern -- bad code or not, the same caveat applies about upgrading core language platforms. Even a strictly typed language with a much more standardized API like Java can be hard to upgrade major versions (where I would consider 5.3 a new major version).
arde 14y ago
It's bad code alright. But I would argue that any code you write in a bad language turns into bad code, no matter how you do it. It might be good enough for your application, so that's fine. But it would be bad nonetheless. And PHP is not a sane language by any measure. So here we have a bad code author dealing with it's bad languague's shortcomings and expecting that they be solved by the very people who created said bad language in the first place. Quite entertaining.

Evbn 14y ago

Wait, endosquid writes tax software and expects that whenever a bit of data gets corrupted it should display an account balance of 0? Please share the name of this phenomenal software product.

SomeCallMeTim 14y ago
I got stuck on "endosquid writes critical tax reporting software in PHP?!", actually.
- alkavan 14y ago
  Yup, indeed this is the main problem here. I work with PHP for many years, but i would not suggest using PHP layer as core of my "Taxing software", PHP is not statically typed means it's not suited well for this job, in e-commerce sites i built in past there were always problems when it gets to tax calculations, you learn to deal with it by wrapping your calculation code in the right way and testing it currently. It is probably the case when unskilled programmers just used number_format() directly instead of wrapping it with "Tax" class that does that you want it to do, and nothing else. it was indeed common in PHP 4, but we have moved since then.
- StavrosK 14y ago
  alkavan's comment on this thread is dead, reposted here: Yup, indeed this is the main problem here. I work with PHP for many years, but i would not suggest using PHP layer as core of my "Taxing software", PHP is not statically typed means it's not suited well for this job, in e-commerce sites i built in past there were always problems when it gets to tax calculations, you learn to deal with it by wrapping your calculation code in the right way and testing it currently. It is probably the case when unskilled programmers just used number_format() directly instead of wrapping it with "Tax" class that does that you want it to do, and nothing else. it was indeed common in PHP 4, but we have moved since then.
Yver 14y ago
Indeed, it's amazing that the same person could say "We are passing a (possibly uninitialized, or null-valued) variable to the function, in hundreds of places and web pages" and "Each of those changes will have to be coded, tested, written-off, released, tested by the clients since this is tax data and has to be precise for tax planning and retirement planning." They are very thorough with testing their super-important tax software. Well, except they ignore uninitialized variables, but I hear those are A-OK in accounting.

josephcooney 14y ago

Way to jump onto a thread that hadn't had any comments in 10-month-old joezimjs and add pretty much zero to the conversation.

fink0136 14y ago

This makes me so excited to be a budding Perl dev.

josephcooney 14y ago

The "is there anyone you can escalate this too" reminds me of a PERL newsgroup thread I saw where someone tried to rip Larry Wall a new one, asking (in a condescending way) him if he knew anything about PERL.

Xcelerate 14y ago
Haha, if you could find that again I'd like to see it!
aidenn0 14y ago
Or the time I suggested on HN that cperciva use scrypt (not noticing the username on the comment).

pippy 14y ago

So developers complain that PHP is not standardised, but when it is in a major version upgrade developers complain that it's becoming standardised?

icebraining 14y ago
Are you somehow under the impression that developers are the Borg? Different developers can have different opinions on what PHP should be.
RobAley 14y ago
A lot of the time, it's developers who don't use PHP who complain its not standardised, and developers who do use PHP who complain when it does change! To be contrary, I'm a PHP developer who likes the on-going standardisation, but didn't really find it too big a problem the existing way. YMMV.

soulclap 14y ago

Related article about the same bug report: "When does a bug turn into a feature?" http://lwn.net/Articles/369505/ http://lwn.net/Articles/369505/

moot 14y ago

> After carefully reviewing this bug report with our board of directors on 4chan, we have come to the conclusion that your "rusty C skills" should be enough to fix the issue. I am sad I was not invited :(

jsilence 14y ago
You should escalate that up at 4Chan!
deleted 14y ago
[deleted]

kevinalexbrown 14y ago

Leaving aside the irony of asking Rasmus to escalate the issue (this would be like complaining in an "Ask HN:" and suggesting that pg escalate the issue up the ycombinator chain), or whether the change was logical or not, I learned something cool from one aspect of Rasmus' response: ... there are many many people out there affected by these changes, we recognize that. That is also why we are not likely to reverse a change like this that others in your situation have now accounted for, tested and deployed in production for many months ... -- rasmus. Good decisions don't always mean everyone goes home happy. Whether or not the change was good or bad, reversing it now could negatively impact anyone else who already adjusted. If it means "MONTHS" of work for this guy, in order to save "MONTHS" of work for 100 others who use PHP, so be it. Even if we were to take a leap of faith and assume it was a bad decision by Rasmus to make the change in the first place, it's been done. Responding to inconsistency with more changes seems like trying to regain your balance by making wilder and wilder swings of your arms.

gcb 14y ago
if you can't do that trivial change on some convulated release system... You don't change php version either. Unless you are addressing security changes. I think its very professional to not bump versions just for the sake of it. release notes exist for a reason.
- webreac 14y ago
  As far as I understood, the release notes were not very explicit or complete (the list of impacted functions were missing) on this issue. Recently I have encountered a problem with redhat migration: /usr/bin/X11/xwd was "moved" to /usr/bin/xwd. I have not found anything in the release note. It is not enough to ask people to read the release notes, these release notes should be complete and usable.
  - TillE 14y ago
    The point is that the release notes will tell you if there are security flaws fixed. There's no substitute for actually testing your code with a new environment before deploying it.

TwoBit 14y ago

In most mature programming languages we resolve this kind of dispute by pointing to the Standard. Is that not possible with PHP?

johnny22 14y ago
Well that's what happened to this guy. He relied on unstandard/undefined behaviour and when php switched to a standard parameter parser it broke his app.

jister 14y ago

In this kind of situation where there's a bug or limitation or some kind of issue with a language function we usually create a wrapper to handle the whatever rules we have internally within the company. In this case the empty string that is supposed to be NULL should be handled within that wrapper function. One function to modify instead of several places in the application.

kyberias 14y ago

People have been wondering "what would Linus have said?" I'm pretty sure he wouldn't have broken the existing (undocumented) behavior in the first place "because it breaks applications and the one and only reason for kernel is to allow applications to run". But then again, PHP is not a kernel. :)

aniket_ray 14y ago
I think you are entirely right. As Linux says "Kernel exists for its users". Pretty similarly, a platform (php/zend) exists for its applications. Linus has always been pretty adamant about not breaking API behaviour even undocumented ones. But in this case, undefined behaviour had been previously documented. Also, was it him or Ulrich Drepper who were against changing memcpy undocumented behaviour. (mempcy used to work with overlapping regions too.) PS. This mailing thread is from 2010. It's really old.
- lmm 14y ago
  Ulrich Drepper was vigorously in favour of it. If your application breaks, it's because it was written wrong.
  - Draiken 14y ago
    Exactly. The only reason this bug got to production, is because the function accepted an empty string parameter in the first place.
- fragmede 14y ago
  Yes, eg: https://lwn.net/Articles/494993/ https://lwn.net/Articles/494993/ Linus took extra steps to no break autofs behavior, even though it was (more) due to a bug in GCC than anything else.

chris_wot 14y ago

Uh, so let me get this straight. They are using number_format, which according to the documentation takes a number and formats as a string, and giving it a string as the input parameter? They were never using the function correctly in the first place! Not sure what they have to complain about here...

rahul342 14y ago

Shouldn't it be raising an exception instead of returning NULL or 0 for ""?!

kenneth 14y ago

There are countless reasons to bash on PHP because, frankly, it is a pretty terrible language[1]. However, this is not a valid reason. The bug reporter is being idiotic and needlessly disrespectful, and is making a big deal out of something that can be easily fixed with a simple `sed` command, as Rasmus demonstrated. And, to be honest, he is clearly demonstrating the fact that he's a pretty poor developer, and that he doesn't have the necessary qualifications to be writing software that manages people's retirement funds. Also, when dealing with something as important as that, you ought to know better than to base our technology on top of PHP. [1]: Coming from somebody who built a very successful startup on top of PHP.

SjuulJanssen 14y ago
"Also, when dealing with something as important as that, you ought to know better than to base our technology on top of PHP." Upon reading the conversation I was amazed he didn't get that response right away.
rbanffy 14y ago
What shocks me most is the sense of entitlement. They downloaded PHP, its behavior changes and they'd rather complain to those who changed it and annoy them until the thing works for them again than fix the bug in their code. If they are not happy with the free product and the free support, there are other options. PHP has its shortcomings, but, as in any open source product, if it doesn't work for you, you have a couple options.
- jiggy2011 14y ago
  Problem is, at that point you have built a lot of business on top of it. So the issue of whether or not it is "free" is moot because it has a very real dollar value to you and also probably to the boss who is breathing down your neck.
  - rbanffy 14y ago
    Then they have a couple options: fork and keep their own fork, they can pay the PHP community (or someone in it) to change it back (or to provide a backwards-compatibility mechanism) or pay developers to change their software to work with newer versions of PHP. They can't bully their way like they tried.

Groxx 14y ago

So the options are: 1. Change thousands of lines of code (probably `sed`-able) 2. Patch PHP to re-introduce the original bug/feature 3. Downgrade PHP back to the version that had the bug/feature you were relying on Why is option 3 not considered in this thread? It was working before, and evidently they can control the version of PHP (since they can patch it). If upgrade breaks X, and you rely on X, don't upgrade. If you need to upgrade for Y, do so, and fix X. That's just how such things work.

sold 14y ago
Problem 1: The old versions do not get security patches. For example, entering the number 2.2250738585072011e-308 hangs the interpreter in old versions, as far as I know this is unpatched in PHP <=5.1. This allows a very effective denial of service. Problem 2: You are delaying the unevitable; it's nice to use new features of the language, having to code in old versions is a pain for developers. Small continuous upgrades are easier to handle than rare gigantic ones.
- Groxx 14y ago
  Small continuous upgrades without ever changing your code is the same cost as a gigantic one without ever changing your code - they either work, or they don't, in variously subtle or spectacular ways. The tipping point lies at some changeset, you just need to hit it. You upgrade, you may need to change things. It's just a fact of life. Or, you pick a library / language / framework / everything that guarantees 100% backwards compatibility as documented, that never has bugs (since fixing those breaks 100% backwards compatibility), and you never use features in even remotely-unexpected ways. Like in this case.
  - Kabacaru 14y ago
    This is why having a good suite of unit tests is so important.
wccrawford 14y ago
3) He said they changed hosts and very few hosts offer old versions of PHP. I don't know if that's correct, but that's what was used as an excuse.

10098 14y ago

Ah, the joys of dynamic typing.

andreasvc 14y ago
No, this is about _weak_ typing (as opposed to strong typing). Static vs. dynamic is another matter.

robryan 14y ago

You can't win, people on one side want this weird behaviour made backwards compatible whereas people complain that the language has a large amount of weird edge cases and should be better standardised around more sane expected values. In this case they were standardising parameter parsing code, which I think is definitely the direction you want to head.

billpg 14y ago

PHP is doing the right thing here. Way back when I first tried PHP out, I tried joining strngs together with a + operator. I made a mistake, but I kept getting back zeros instead of some sort of NULL or an exception. This is a bug, in the sense of its not how I wanted PHP to behave. I'm glad PHP is fixing its string-to-numeric bugs.

olleicua 14y ago

Here's to not using PHP for anything serious! The whole point of a dynamically typed language is that arguments could be of any type. Language built-ins should account for this. Of course PHP doesn't and shouldn't be expected to. The fact that Facebook, MediaWiki, and WordPress are so successful is still a mystery to me.

ceejayoz 14y ago
> The fact that Facebook, MediaWiki, and WordPress are so successful is still a mystery to me. The fact that some developers think the language chosen has much effect on the success of a site is still a mystery to me.

buster 14y ago

All the discussion aside, there is so much wrong with it: First of all, why does the function even accept strings? There should be some eception happening. Second, why does it return 0, i could understand NULL but not 0 (for a function that is supposed to handle numbers, having it return a number in the invalid case, what is that?)

RobAley 14y ago
PHP is a dynamically typed language, so although it expects a number, it will accept a string as it will try and parse that string into a number (e.g. you could pass it the string "2.23232" and it will work in the same way as if you pass it 2.23232 as a float). In this particular case, as the empty string can't be parsed into a number, it does indeed throw a PHP warning and treats it as a null input. My understanding is that it used to return 0 and that was considered a bug by some (although others, including the author of the function, decided that as the return type was a number it should ALWAYS return a number). The change that is under "dispute" in this case is that it has indeed been changed to return null, which is what most people now agree is the best way, and is consistent with other PHP functions.
- jablan 14y ago
  I believe you are refering to strongly vs weakly typed, not statically vs dynamically typed. A strongly typed language would not try to parse the string into a number (although it would indeed accept a string, if it is dynamically typed as well).
  - RobAley 14y ago
    I did indeed mean weakly typed (PHP is both dynamically and weakly typed). Haven't had my coffee yet this morning.
masklinn 14y ago
> First of all, why does the function even accept strings? Why not? > There should be some eception happening. PHP's built-in functions do not ever throw exceptions. > Second, why does it return 0, i could understand NULL but not 0 Well it doesn't anymore, but it used to, and that kind-of made sense in the context of the language being PHP: in PHP (userland), when using a string in a numeric context that string will automatically be converted to a number: > php -r 'print (1 + "3") . "\n";' 4 when the string can not be parsed to a number (meaning it is not prefixed by something which looks like a number), it's just converted to `0`: > php -r 'print (1 + "whelp") . "\n";' 1 And I expect that is the former behavior of the function: it coerced whatever it got to a number, so an empty or non-numeric string would get converted to the float 0.0, which would then get formatted as usual.

wanderr 14y ago

I have to agree with the bug submitter in concept, if not in attitude. PHP is a dynamically typed language. As such, methods should expect surprises about the types of data received. Seriously, I've had PHP treat the same input as a string one time, an interface another, it's like it uses whatever is convenient at the time. If you neeeeed that data to be an int, cast it as an int, don't punish the user because type system chose a different type this time. Additionally, and more to the point, in PHP 0 == "" == null == false, so it shouldn't be unreasonable to expect them to be treated as equivalent. It's also a nice thing when a method can always be trusted to return the same type, or these types of issues can end up cascading. In any case, 'should' and 'nice' things are hard to rely on in PHP, that's why you should always have the docs open and read everything when writing PHP, making even basic assumptions about a method being well behaved will likely screw you over. :)

Terretta 14y ago
Especially for a novice, formatting a field on a web form into a number, and seeing PHP format an empty field as zero, so you can carry on with your math, makes sense. "Oh, web parsing language, sees empty number field as zero, great!" Principle of least surprise "for the novice web developer" says empty string to zero makes sense in this case. Meanwhile, empty string with zero decimal places returning null would be less surprising to a pro, but in PHP, the first behavior would also be unsurprising to a pro.

sneak 14y ago

In April 2010 Rasmus Lerdorf joined WePay (a YC startup) in a senior position. http://techcrunch.com/2010/04/27/php-founder-rasmus-lerdorf-joins-group-payments-startup-wepay/ http://techcrunch.com/2010/04/27/php-founder-rasmus-lerdorf-... He's always been like this, best I can tell.

deepGem 14y ago

"Please escalate this to someone who can answer the question as to why this was changed. If no one knows, then why was default behavior changed?" Mr.Rasmus, respect, for not ending the thread at this statement.

robryan 14y ago

In the same way that projects enforce a certain subsection of c++, it is probably best in PHP to not code anything in a way that relies on unusual quirks of the language to work. None of my code gets bitten here because I never passed number_format anything but numbers.

andreasvc 14y ago
In my opinion weak typing is an unusual quirk, but there's no way to get around that. I really wonder kind of reasons could be given to defend it; I don't think a strongly typed language like Python is any harder because of its types.
- robryan 14y ago
  I tend to agree, these days where possible when working in PHP I try not to rely on PHPs magic type conversions behind the scenes for things like comparisons.
  - andreasvc 14y ago
    You can't really avoid weak typing; e.g., making a mistake in a strongly typed language would raise an error, whereas in a weakly typed language it can silently screw up everything.

methodin 14y ago

Blaming your problems on the person making something you are consuming is always a useless endeavor. Make a function if you are using something in hundreds of places that relies on user input. Not terribly difficult.

ndrw 14y ago

The documentation is right and the "engineers" are wrong! And it's also a good example why you should stay away from using undocumented stuff. If the documentation says "float $number" you best better give it a float, dammit! Engineers, my a$$...

snorkel 14y ago

Headline of this post is totally false and this is not even a bug in PHP, it's clearly a bug in the poster's code, so Rasmus response is right. If you actually try doing this in PHP you get this: print number_format("",0); Warning: number_format() expects parameter 1 to be double, string given in Command line code on line 1 So the poster willfully ignored the warning. You can fix this simply by casting the first arg as a numeric type: print number_format((int)"",0); 0 Please, if you're this bad at programming and you willfully ignore warnings, don't file bugs, and please do not take a programming job at some place that does important things like air traffic control, banking, or life support systems.

DHowett 14y ago
The headline of this post is such because it is quoting a PHP developer on a point made in a later comment on the report.
- xd 14y ago
  The quote was tongue in cheek.
psaintla 14y ago
I think there are two bigger issues: 1.) Things like this should not be warnings in the first place. There should be more strict handling of invalid input so they result in actual exceptions being thrown instead of output that can be exploited in incorrect/undocumented ways. 2.) The php.net documentation for number_format doesn't even state that NULL is a possible output value. And I can't find anything in the changelogs stating when this change was made (admittedly I glanced quickly so I may have missed it) You state that it is a bug in PHP, but I respectfully disagree. This is a bug in the varied way in which PHP returns output based on invalid input. Some functions return 0, some functions return NULL, some functions return FALSE and it seems as if it is all done arbitrarily. This really should end, invalid input should result in standard exceptions being thrown so they can be handled.
- wpietri 14y ago

lnanek2 14y ago

This is pretty standard with large production software. You often see grids in the documentation, e.g. this version of the app server is only certified for these brands and versions of Java. Even if you have a paid support contract with us, do not contact us re using it on something else. So in the reporter's case, their software just isn't certified for the new version until updated. No big deal. I remember working at a company where the servers were Ubuntu, the auto-update mechanism replaced Sun Java with OpenJDK which broke countless apps and web servers, like the Concur app, the build system, etc.. God that was a nightmare. A real setup like at bigger companies I've worked at would have tested that update on developer boxes, integration boxes, testing and training boxes, and only then sent it to production.

gedrap 14y ago

It was really to read that conversation. I do not care whether it was a good or bad decision to make those changes in PHP but you simply can not talk like that to a person who has put thousands of hours of unpaid work (while he could get a fat pay check easily) and you are making living because of what he has done. It's just immature.

Darkstar 14y ago

Everybody was in the wrong here. The developer should've written better code. I'm a PHP developer and I've learned that if the input is that important, I need to cast it. I've used C++, C#, and Java and I like strict typing. If your application is that sensitive then maybe it should've casted the input to ensure the output is consistent. As for Rasmus, I think he could've explained why it's a "won't fix" type bug in a slightly more diplomatic fashion, though I can't say I would've handled it any differently. He's completely right as to why the behavior shouldn't change. Finally, bjori's response was completely unnecessary, inflammatory, and downright rude. This has shown me the worst of the PHP community. I'm not ashamed, just more wary.

ericingram 14y ago
This is exactly how I feel about it. I think it's an example of how not to interact in a community, from both angles. Also, I can't stand the notion that open source developers are "volunteering" their effort. All programming is voluntary in the sense that you are making a free choice to do it and most likely gaining capital (social or financial) in the process. I voluntarily build software and give or sell it to others all the time.

ivanhoe 14y ago

Issue here is not whether it can be fixed, anything can be fixed. Issue here is why in the world they have changed things in a such way to break the old code?! Was it necessary? I don't think so... I understand the need to re-factor, and making some old stuff obsolete along the way, of course, but it's not the case here. It's just that someone wasn't really playing attention to this. And this type of negligence to the details is really killing php as language. If after 10+ years in php I need to re-read the manual every now and then to make sure if the things are still working like the last time, it's just crazy..

Killswitch 14y ago

| ^ 0 isn't some magic all-encompassing number. It means 0. NULL means no number based on your shitty incorrect input, and is the correct choice. Best response to the whole thing except for Rasmus' awesomeness.

strictfp 14y ago

Stop doing automagical conversions and all these problems will go away.

prisonguard 14y ago

a pal of mine recently upgraded a big corp's pcs from win xp to win 7 . the long wait was due to excel macros which could not run in the latter os. they couldnt switch even after him rewriting and testing them to run. [edit] typo

peterkelly 14y ago

... and that's why you don't use PHP.

deleted 14y ago

[deleted]

pbiggar 14y ago
I've flagged your comment. Please remove it. Just because we observe somebody being a dick on the internet, does not give us permission to stalk them, expose their personal information (even if it can be freely found on the internet), round up a lynch mob, etc. This is very bad behaviour on your part. This sort of thing can ruin lives. Please take it down.
- deleted 14y ago
  [deleted]
  - StefanKarpinski 14y ago
    I'm happy to remove the comment. What guideline is this in direct opposition to? Genuine question, not being snarky.
    - pbiggar 14y ago
      Its in the footer: http://ycombinator.com/newsguidelines.html http://ycombinator.com/newsguidelines.html
      - StefanKarpinski 14y ago
        "Be civil."?
        pbiggar 14y ago
        Probably also "Don't say things you wouldn't say in a face to face conversation." (at least, I hope so)
    - deleted 14y ago
      [deleted]

loup-vaillant 14y ago

> Find the dependencies —and eliminate them Excel team motto.[1] While I understand Rasmus' response is legitimate, I also see that depending on something as crucial as a programming language implementation is less of a good idea than it might seem at first. Makes things like Maru (the programming language[2], not the cat) much more appealing: if there's something you don't like in your compiler, at least you stand a chance at fixing it (Maru is less than 2K lines, and counting down). [1]: http://www.joelonsoftware.com/articles/fog0000000007.html http://www.joelonsoftware.com/articles/fog0000000007.html [2]: http://piumarta.com/software/maru/ http://piumarta.com/software/maru/

deleted 14y ago

[deleted]

cldrope 14y ago

I think the guy wasn't thinking the situation through entirely, but someone of (relative respect I suppose, creator of PHP is still the creator of something widely used) respect shouldn't be acting like this. It's always a shame to see people who have promise and talent show how childish they CAN act. Having his underling (someone who works on his language of no known note) make a smartassed response was in turn also pointless and negative whether he requested/urged it passively or not.

FuzzyDunlop 14y ago

> Each of those changes will have to be coded, tested, written-off, released, tested by the clients since this is tax data and has to be precise for tax planning and retirement planning. Considering the filer of the report goes on to say this, at what point did they fail to realise that moving from an "old PHP 5.1.6 Solaris 8 box" to an "RHEL5 with 5.3.1" should have required the same level of testing and signing off? No sympathy for a developer who completely changes their environment (OS, PHP version, at the very least) and then bitches about stuff they failed to anticipate not working. This is not a reflection on PHP, for once.