Not so long I got bitten by string array keys being silently converted to int when they can be interpreted as numeric, but not all numeric. The OP almost mentions this mixed in with the JSON encoding/decoding:
Strings containing valid decimal ints, unless the number is preceded by a + sign, will be cast to the int type. E.g. the key “8” will actually be stored under 8. On the other hand “08” will not be cast, as it isn’t a valid decimal integer.
While I agree this can be a pitfall, this has some misguided points.
You should probably look up how arrays work before you use them. In my experience (which was a while ago, but PHP 5 days) stdClass was very, very rarely used, especially from JSON. Every piece of code I’ve ever worked with used JSON_OBJECT_AS_ARRAY and it just worked. Yes, you have to know to use foreach with arrays, unless you built it yourself with numeric keys. That’s not great, but it’s essentially a non-problem.
Pitfall notwithstanding, I find deserializing to objects from JSON a little dangerous, so unserializing to dictionary and then checking your input before constructing an object was done manually all the time anyway, not just in PHP but I am not sure if sensibilites have changed here
You should probably look up how arrays work before you use them.
This statement is extremely true for PHP and only partially true for most everything else. PHP has named a datastructure a name with well understood meanings by almost all languages in common use. It shared similar syntax for defining them. In every way it is shouting to the user: “You know this. It’s an array”. And then when you are least expecting with absolutely 0 warning it goes and breaks those perfectly reasonable assumptions you had.
PHP is somewhat unique in this. Not entirely by itself, but the class of languages that make this mistake is very small. For all of them it is very much a mistake though.
Kind of similar with nix calling a dictionary/map/hash a “set”. At least that one is very obviously not-a-set. (Then again hash is an abused name already)
No disagreement here. But it’s literally the first sentence on the page on arrays in the manual. I honestly wonder if you can run into this problem by first reading example code that only uses integer keys? Because how would you know it’s = array() or = [] otherwise?
Most people treat the manual as a reference and do their actual learning from a tutorial or examples online. They may never look at the manual entry for an array until they realize it’s not strictly speaking an actual array. Which in practice means not until it breaks their assumptions. This is not an unreasonable way to proceed for most programming languages. But in PHPs case it’s going to lead to sadness eventually. I’m unsympathetic to arguments that it’s their fault for not reading the manual. It’s PHP’s fault for being confusing, surprising, and violating totally reasonable assumptions in their language.
This is the obvious evidence that it is a language that focused so much on utility/pragmatism that it borderline ofenses those trying to make sense of it from a theoretical point of view. I am half joking of course.
It is quite funny that an array can be used as a list, a
(de)dueue and a map, but what it is not… Is an array. It does offer syntax for random access, but the lookup performance is poor (linear?) AFAIK.
The article could be written a bit more correctly. These are well defined data structures. Not concepts introduced by other languages. A list is NOT and order of elements with different types. Some languages offer that possibility but I would argue that doing so is a very bad idea and if you do it, you are probably doing it wrong.
As per the other data structure, the widely used name name is map. Dictionary refer to python specifically.
PHP is a tool. The functionality is there, compared to the alternatives that existed when it was created, it was such a conclusive improvement that it is even embarassing. Theoretical correctness was left up to the programmer. Indee, or you are going to create and array using multiple types or treat it both as a map and a list, you are going to have many bar surprises. That’s for sure. You are naive if you believe this is the languages fault. It’s not.
Not so long I got bitten by
stringarray keys being silently converted tointwhen they can be interpreted as numeric, but not all numeric. The OP almost mentions this mixed in with the JSON encoding/decoding:WAT:
Oh yes, that’s always a fun one to find by accident. My favourite WAT that I found is that this is valid:
Fun to figure out why…
While I agree this can be a pitfall, this has some misguided points.
You should probably look up how arrays work before you use them. In my experience (which was a while ago, but PHP 5 days) stdClass was very, very rarely used, especially from JSON. Every piece of code I’ve ever worked with used JSON_OBJECT_AS_ARRAY and it just worked. Yes, you have to know to use foreach with arrays, unless you built it yourself with numeric keys. That’s not great, but it’s essentially a non-problem.
Pitfall notwithstanding, I find deserializing to objects from JSON a little dangerous, so unserializing to dictionary and then checking your input before constructing an object was done manually all the time anyway, not just in PHP but I am not sure if sensibilites have changed here
This statement is extremely true for PHP and only partially true for most everything else. PHP has named a datastructure a name with well understood meanings by almost all languages in common use. It shared similar syntax for defining them. In every way it is shouting to the user: “You know this. It’s an array”. And then when you are least expecting with absolutely 0 warning it goes and breaks those perfectly reasonable assumptions you had.
PHP is somewhat unique in this. Not entirely by itself, but the class of languages that make this mistake is very small. For all of them it is very much a mistake though.
Kind of similar with nix calling a dictionary/map/hash a “set”. At least that one is very obviously not-a-set. (Then again hash is an abused name already)
Ugh yes I hate that so much.
No disagreement here. But it’s literally the first sentence on the page on arrays in the manual. I honestly wonder if you can run into this problem by first reading example code that only uses integer keys? Because how would you know it’s
= array()or= []otherwise?Most people treat the manual as a reference and do their actual learning from a tutorial or examples online. They may never look at the manual entry for an array until they realize it’s not strictly speaking an actual array. Which in practice means not until it breaks their assumptions. This is not an unreasonable way to proceed for most programming languages. But in PHPs case it’s going to lead to sadness eventually. I’m unsympathetic to arguments that it’s their fault for not reading the manual. It’s PHP’s fault for being confusing, surprising, and violating totally reasonable assumptions in their language.
Broadly, this applies to everything in every language. In practice, though, it’s helpful to have words mean predictable things.
This is the obvious evidence that it is a language that focused so much on utility/pragmatism that it borderline ofenses those trying to make sense of it from a theoretical point of view. I am half joking of course.
It is quite funny that an array can be used as a list, a (de)dueue and a map, but what it is not… Is an array. It does offer syntax for random access, but the lookup performance is poor (linear?) AFAIK.
The article could be written a bit more correctly. These are well defined data structures. Not concepts introduced by other languages. A list is NOT and order of elements with different types. Some languages offer that possibility but I would argue that doing so is a very bad idea and if you do it, you are probably doing it wrong. As per the other data structure, the widely used name name is map. Dictionary refer to python specifically.
PHP is a tool. The functionality is there, compared to the alternatives that existed when it was created, it was such a conclusive improvement that it is even embarassing. Theoretical correctness was left up to the programmer. Indee, or you are going to create and array using multiple types or treat it both as a map and a list, you are going to have many bar surprises. That’s for sure. You are naive if you believe this is the languages fault. It’s not.
It is the language’s fault, but it’s not unique to PHP. For example, Lua’s tables have similar ergonomic issues.
Pretty sure PHP arrays are implemented as hash tables and random access lookups are constant time.