The array key thing doesn't crop up often, but I've had it happen. Sometimes you are parsing something, such as "all files in this directory" and want to use the filename as the key and maybe store metadata or something as the value. Well, the second one of those filenames looks like a number, you're basically screwed. Now your array has some string keys and some int keys and operating on it is inconsistent at best.
And, you're right, of course that Apache and Nginx don't actually support PHP out of the box. It's been a bit since I've configured a server and I forgot that mod_php is an extra step. That is definitely the main "pro" to using PHP, though- the deployment is great and so easy I can literally forget it. ;)
Yeah, alright, I understand your example now but I would argue that it's more of a problem with actually using filenames as array keys than it is a problem with PHP.
Even so, wouldn't you be able to ensure that it's a string by doing `$array[(string)$filename] = ...`? (Again, I don't think using filenames for array keys—in any language—is a good idea but we're theorycrafting here.)
> Yeah, alright, I understand your example now but I would argue that it's more of a problem with actually using filenames as array keys than it is a problem with PHP.
No. Just no. There is no reason, a priori, that you can reason that filenames shouldn't be keys in a hashmap. I think you're just projecting from "can't be done reliably in PHP" to "software should not do it" which are NOT the same things. Seriously. What is it about filenames that causes you to think "No. There's never a good reason to map a filename to data without defining a whole new type"? What other things scream out to you that should never get to be keys for dictionaries? Names? Planets? Flavors of candy? Would you really believe this if you were working in another language?
It's exactly this reasoning that drives me nuts about PHP. You can point out the most insane behavior and someone always comes by and says "Nothing to see here. Just don't do that." Or "I just know not to do that, therefore PHP is fine."
> Even so, wouldn't you be able to ensure that it's a string by doing `$array[(string)$filename] = ...`? (Again, I don't think using filenames for array keys—in any language—is a good idea but we're theorycrafting here.)
Nope. Doesn't fix it. Because it's only converted to an int after being passed in. $filename was already a string. You're casting a string to a string and PHP, in all its wisdom, is then making it an int.
And I think it speaks to my point that you tried and failed to solve the issue. That's not an affront to you, by the way. It's more evidence that PHP is impossible to do correctly.
> You can point out the most insane behavior and someone always comes by and says "Nothing to see here. Just don't do that." Or "I just know not to do that, therefore PHP is fine."
I'm pretty sure what you're describing there is every programming language—or any object of fancy really. People tend to defend the things they like.
However, PHP wasn't even my reason for not wanting to use filenames as array keys. You're reading WAY too much into my response. And maybe you're right, maybe it's fine to use filenames as keys, but my initial thought was that maybe some programming languages weren't too happy about using e.g. emojis as keys so I'd prefer to be a bit more in control of what ended up in my keys, but I guess a string is a string (except when it's not ... apparently).
> Would you really believe this if you were working in another language?
I'm not even primarily working with PHP. I just don't have any huge issues with it and its quirks. You're not gonna hear me deny that it has its inconsistencies but I don't feel like I'm spending more time fighting the language than I save by developing in it, so for me it comes out as a net positive still.
> And I think it speaks to my point that you tried and failed to solve the issue.
I disagree. First of all, I gave you the very first idea that popped into my head without even knowing at what point the bad type-casting occurred. It was even phrased as a question specifically because I wasn't sure if it would fix it. Second, I would argue that this is an edge-case. I've done PHP on and off for a long time ("off" for at least the last 6 months though) and I've never run into this before. Or maybe I have, but then it hasn't been a problem because I usually don't mix associative and numerically indexed arrays, so `$arr['123']` would still find `$arr[123]` and I'd likely never notice what was actually happening underneath.
Oh, come on, don't try to defend a PHP design flaw by blaming people who use perfectly valid file names, and people who do perfectly valid things like using file names as array keys.
Can you actually refer me to a programming language style guide that says not to use file names as array keys, or are you just pulling that out of your ass -- I mean theorycrafting?
I've got a great idea, inspired by mysql_real_escape_string:
PHP should have a real_array() function and data type that doesn't screw you when you use file names as keys! Now we just have to get all the php programmers to defensively use the "real" version of every function and data type, just in case. And also a linter that complains when you use functions without the word "real" in them.
Sarcasm aside, can we please stop blaming the victims to whitewash PHP's obvious design flaws?
> or are you just pulling that out of your ass -- I mean theorycrafting?
That seems really uncharitable, he's just trying to better understand the issue and reason about why it may not have been an issue for him. Can we not all agree that if there are objective flaws in PHP, speaking about it objectively might be the simplest way to communicate it? I feel like you're quite emotionally charged, which isn't always a bad thing but I could imagine it being quite discouraging for other people to deal with.
I'm still confused about the array keys though. I'm not sure I understand the example you gave in your other comment.
And I'm also curious which Apache and Nginx has PHP installed and enabled by default.