god, the time i spent going paranoid debugging a stray "undefined array index 0" just to find out
array_filter(
is_uppercase,
['a', 'B', 'c', 'D']
)
returns [1 => 'B', 3 => 'D']
and not ['B', 'D']
like every other `filter(...)` i've used...EDIT to be fair, i see the rationale – having the index of the filtered element is useful sometimes, and requires some contortions with the usual impl of filter. it's quite neat, because you get both the index and the elements! but it's just... surprising as the default, and PHP's conflation of maps and lists obscures it – all the docs say is "array keys are preserved", which makes sense in retrospect, but doesn't really jump out for something with this much impact
a = []
a.foo = 'bar' // works!
b = {}
b[0] = 42 // also works!
I happen to think these designs are both INSANE, but even if you like them, PHP has no advantage here.https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Arrays are objects of class Array which have special literals, override the toString() method, and update the non-enumerable "length" property on certain operations.
Try calling Object.keys([1, 2, 3]), or even better try Object.getOwnPropertyNames([1, 2, 3])
https://www.stefanjudis.com/today-i-learned/property-order-i...
[1] So how do arrays have numerical keys? Well... actually they don't. I was trying to make JS look better than it is in my original comment. Actually, array keys are stringified versions of numbers, and values are automatically cast to string when you put them in indexing braces.
Object.keys([1, 2])
--> ["0", "1"]
As you can imagine, this leads to gotchas when you assume that a JS object can have, say, a date as a key b = {}; b[new Date()] = 10;
Object.keys(b)
--> [
"Sat Nov 09 2019 23:15:58 GMT-0800 (Pacific Standard Time)"
]In Zend/zend_types.h[1] of PHP source:
typedef struct _zend_array zend_array;
typedef struct _zend_array HashTable;
struct _zend_array {
...
};
That being said AFAICT, HashTable and zend_array are used interchangeably throughout the source. I am not a C programmer, but I did write a couple of PHP extensions and that was my general understanding. Perhaps it is a compatibility issue or just used to abstract types differently in various areas of the C API.Check out [2] for a deeper understanding of how arrays are handled internally in PHP.
[1]: https://github.com/php/php-src/blob/php-7.3.11/Zend/zend_typ...
[2]: https://nikic.github.io/2014/12/22/PHPs-new-hashtable-implem...
I disagree with you on this point. I worked with PHP for two years on some legacy systems, as well as some Laravel-based systems. While Laravel yields results that are worlds away from PHP build in the 90's, I still wasted dozens of hours because of poor constructs that the language is unfortunately coupled to. I documented each instance where I wasted a significant amount of time due to issues like scoping issues, closure problems, arrays-that-are-arrays-sometimes-but-maps-other-times, etc.
PHP has gotten better. But there are so many good choices that provide much better tooling, guarantees, etc. Examples: Ruby, Go, and Elixir. Heck, even Perl is more sane about its data types in some ways by enforcing consistent comparisons with `==` vs. `eq` and much more robust data structures.
I agree that every language has it's quirks. But I think PHP has so many that it seriously gets in the way often. I don't think it offers any significant velocity gains over using, say, Ruby.