The developers at my $work already know I hate PHP with a passion (and most of them do too). Here is a nugget of... I'll let you decide, that shows another interesting... err.. uh... feature?
php > $a = array('a','b','c');
php > unset($a);
php > var_dump($a);
What you see here is setting a variable in a PHP REPL shell. The variable is an array. Then we remove the second element in the array (index no. 1) and then dump the array with the indexes.
Do you see the problem? Let me iterate further (excuse the pun). When you remove the second element in an array, you would expect the third to now become the second, the fourth becoming the third, and so on. First of all, because it makes perfect sense. Secondly, when you iterate over the array, you don't have any holes and gaps, causing segfaults or unexpected behavior (at the worst case) or exceptions raised (at the best case). Did I mention possible security problem?
However, apparently in PHP, you can remove an element from an array and the array will act like a hash with the indexes as the keys. It will maintain the old index and not update it.
Perl, on the contrary...
In Perl, the way to do this wouldn't be to
undef the variable but to
splice it out. Splicing it correctly sets the indexes of every element and makes sure it's done right. It even returns the value if you want it, or just replaces it inline with another. However, suppose that PHP has a way to do this as well, the above result is still fscked up. This is what would happen if I decide to simply
undef an array element in Perl (demonstrated in Devel::REPL:
$ my @a = ( qw( a b c ) );
$ARRAY1 = [
$ undef $a;
$ARRAY1 = [
It keeps the index and the indexed item, but the value is