6 ms·

> if you try to use a string as a key, but it is a string of digits. It will automagically(sic) convert your string to an int and totally F-up your dictionary

> if you try to use a string as a key, but it is a string of digits. It will automagically(sic) convert your string to an int and totally F-up your dictionary I've been a PHP programmer for over 15 years and I cannot think of a single time this has been an actual problem. It sounds like you were embarrassed by a bug in your code and have just decided to blame it on the tools.

paulryanrogers 7y ago
I've run into that numeric reindexing confusion. PHP arrays in general are so feature rich it's also easy to overuse them. The proliferation of Collection classes may be one side-effect of how poweful-yet-awkward they are.
- ragnese 7y ago
  Is "powerful" really even the right description? I can't even do a map + filter without looping through the array twice. Ew. I guess I'll just stick with the primitive foreach loop (which leaves a dangling allocated object after you use it... sigh).
jrumbut 7y ago
My guess is that the numeric indexing thing happens a lot but it's definitely rare for it to cause a visible problem and even rarer to be identified as the cause since it is unexpected. I've been bitten by it and also stuff like 800=="8E2". I've never been able to make an adequate defense of PHP, yet also have never seen another language match its success rate of getting useful software into the hands of users. I have wondered whether something about PHP, or something that it lacks, makes PHP projects easier to estimate. Ease of deployment? Batteries included standard library? Pragmatic community? Surprisingly adequate performance? It never seems like enough to overcome the obvious deficits. I can neither ignore my own experience nor convince anyone that it's actually great.
- ragnese 7y ago
  I'm in a similar boat. I've decided that whatever it is that makes PHP successful must be exactly the same thing that has made JavaScript successful. It's going to sound extremely condescending, but here it is, anyway: I believe that the majority of people who defend PHP (and JavaScript) are people who have ever only written code in Java (especially <=1.6), JavaScript, and PHP. Maybe C for fun or in college. In light of those immensely popular languages, I could see why someone might not think that any of the deficiencies are deal-breakers.
  - jrumbut 7y ago
    Maybe, in my case since I am currently in the non-PHP phase of my alternating PHP/non-PHP job history. PHP has been less than 50% of what I've done (the rest being far more on-trend, if you will) though disproportionately represented among successful and profitable projects. The only-ever-PHP coders I have known tend to be fairly polarized between fear of the unknown and the "grass is greener" attitude. The ease of estimation thing was an aside, but I'm getting more convinced. With PHP there is only one way to do any feature: look up the library function, type it, refresh the page, and slowly accrete your functionality. With other languages there's some hope of a free lunch and it engages our tendency to optimism.
    - tnorthcutt 7y ago
      With other languages there's some hope of a free lunch and it engages our tendency to optimism. Asking as someone who's mostly only written PHP (and some javascript, more recently): can you expand on this? What kind of "hope of a free lunch" is there with other languages?
      - jrumbut 7y ago
        I think there are a few, and maybe I am the only one who has ever been foolish enough to think these things or incompetent enough not to achieve them. The first is the promise of DSLs and meta programming, where you can tune the syntax of the language to more naturally express your problem domain. When this works it's beautiful, but sometimes it is a distraction and makes the code difficult to debug. The second, which is conceptually very different but I find it can play out similarly, are rich type systems where you can hopefully build up your application as a series of well defined type relations and transformations. Again, when this works you get really robust, reliable, and easy to modify software but there are often cross cutting concerns or business practices that break the model. Edit: when I talk about a free lunch or a silver bullet, I am often thinking about the writing of Fred Brooks.
thaumaturgy 7y ago
It's a real-life problem. I just recently stepped in it while working on some software that interfaces with imap. A couple of folders were named "2018" and "2019" and common array*() operations kept blowing up with those keys. I ended up building out a whole new array class to work around it. The notes at the top of my class file pretty well describe the problem: https://github.com/robsheldon/asinius-core/blob/master/src/Asinius/StrictArray.php https://github.com/robsheldon/asinius-core/blob/master/src/A... There are native-php workarounds and if you're very very careful you can probably maybe encounter this and code around it without triggering any of the strange behaviors, but it's a minefield. I'm not new to PHP, either. I think by chance people just usually don't encounter the circumstances for this particular bad behavior, but when it happens, it's really bad. Array keys shouldn't be getting implicitly typecasted.
munk-a 7y ago
I agree that the issue mentioned above isn't that bad - as a long time PHP developer (and PHP admirer) one gotcha that still really annoys me is persistence of key refs outside of foreach loops and I present this eval[1] as a wonderful example of why you should really prefer array_map for mutating array values or be very pedantic about unsetting variables when you leave a foreach using ref loop. 1. https://3v4l.org/99pMn https://3v4l.org/99pMn
- ragnese 7y ago
  Except that if you do anything other than mapping, you start taking a performance hit. If you want to use array_map with array_filter, you're now iterating your array twice. Also, if you ever use array_filter, you almost certainly need to wrap it in array_values, so now you're looping N times. It's no wonder people still lean on the broken foreach. I always use unset() after foreach. It makes me die inside a little.
ragnese 7y ago
You remember every bug you've written in 15 years? I'm not that talented. I write bugs all the time. Most of the time, tests save me. You can size me up as just childishly trying to divert blame when I made a mistake, but you're missing out by doing so.

paulryanrogers 7y ago

I've run into that numeric reindexing confusion. PHP arrays in general are so feature rich it's also easy to overuse them. The proliferation of Collection classes may be one side-effect of how poweful-yet-awkward they are.

ragnese 7y ago
Is "powerful" really even the right description? I can't even do a map + filter without looping through the array twice. Ew. I guess I'll just stick with the primitive foreach loop (which leaves a dangling allocated object after you use it... sigh).

jrumbut 7y ago

My guess is that the numeric indexing thing happens a lot but it's definitely rare for it to cause a visible problem and even rarer to be identified as the cause since it is unexpected. I've been bitten by it and also stuff like 800=="8E2". I've never been able to make an adequate defense of PHP, yet also have never seen another language match its success rate of getting useful software into the hands of users. I have wondered whether something about PHP, or something that it lacks, makes PHP projects easier to estimate. Ease of deployment? Batteries included standard library? Pragmatic community? Surprisingly adequate performance? It never seems like enough to overcome the obvious deficits. I can neither ignore my own experience nor convince anyone that it's actually great.

ragnese 7y ago
I'm in a similar boat. I've decided that whatever it is that makes PHP successful must be exactly the same thing that has made JavaScript successful. It's going to sound extremely condescending, but here it is, anyway: I believe that the majority of people who defend PHP (and JavaScript) are people who have ever only written code in Java (especially <=1.6), JavaScript, and PHP. Maybe C for fun or in college. In light of those immensely popular languages, I could see why someone might not think that any of the deficiencies are deal-breakers.
- jrumbut 7y ago
  Maybe, in my case since I am currently in the non-PHP phase of my alternating PHP/non-PHP job history. PHP has been less than 50% of what I've done (the rest being far more on-trend, if you will) though disproportionately represented among successful and profitable projects. The only-ever-PHP coders I have known tend to be fairly polarized between fear of the unknown and the "grass is greener" attitude. The ease of estimation thing was an aside, but I'm getting more convinced. With PHP there is only one way to do any feature: look up the library function, type it, refresh the page, and slowly accrete your functionality. With other languages there's some hope of a free lunch and it engages our tendency to optimism.
  - tnorthcutt 7y ago
    With other languages there's some hope of a free lunch and it engages our tendency to optimism. Asking as someone who's mostly only written PHP (and some javascript, more recently): can you expand on this? What kind of "hope of a free lunch" is there with other languages?
    - jrumbut 7y ago
      I think there are a few, and maybe I am the only one who has ever been foolish enough to think these things or incompetent enough not to achieve them. The first is the promise of DSLs and meta programming, where you can tune the syntax of the language to more naturally express your problem domain. When this works it's beautiful, but sometimes it is a distraction and makes the code difficult to debug. The second, which is conceptually very different but I find it can play out similarly, are rich type systems where you can hopefully build up your application as a series of well defined type relations and transformations. Again, when this works you get really robust, reliable, and easy to modify software but there are often cross cutting concerns or business practices that break the model. Edit: when I talk about a free lunch or a silver bullet, I am often thinking about the writing of Fred Brooks.

thaumaturgy 7y ago

It's a real-life problem. I just recently stepped in it while working on some software that interfaces with imap. A couple of folders were named "2018" and "2019" and common array*() operations kept blowing up with those keys. I ended up building out a whole new array class to work around it. The notes at the top of my class file pretty well describe the problem: https://github.com/robsheldon/asinius-core/blob/master/src/Asinius/StrictArray.php https://github.com/robsheldon/asinius-core/blob/master/src/A... There are native-php workarounds and if you're very very careful you can probably maybe encounter this and code around it without triggering any of the strange behaviors, but it's a minefield. I'm not new to PHP, either. I think by chance people just usually don't encounter the circumstances for this particular bad behavior, but when it happens, it's really bad. Array keys shouldn't be getting implicitly typecasted.

munk-a 7y ago

I agree that the issue mentioned above isn't that bad - as a long time PHP developer (and PHP admirer) one gotcha that still really annoys me is persistence of key refs outside of foreach loops and I present this eval[1] as a wonderful example of why you should really prefer array_map for mutating array values or be very pedantic about unsetting variables when you leave a foreach using ref loop. 1. https://3v4l.org/99pMn https://3v4l.org/99pMn

ragnese 7y ago
Except that if you do anything other than mapping, you start taking a performance hit. If you want to use array_map with array_filter, you're now iterating your array twice. Also, if you ever use array_filter, you almost certainly need to wrap it in array_values, so now you're looping N times. It's no wonder people still lean on the broken foreach. I always use unset() after foreach. It makes me die inside a little.

ragnese 7y ago

You remember every bug you've written in 15 years? I'm not that talented. I write bugs all the time. Most of the time, tests save me. You can size me up as just childishly trying to divert blame when I made a mistake, but you're missing out by doing so.