Re: Re: list() limitations

From: Date: Sat, 06 Apr 2002 09:41:51 +0000
Subject: Re: Re: list() limitations
References: 1 2  Groups: php.dev 
Request: Send a blank email to php-dev+get-82190@lists.php.net to get a copy of this message
On Sat, Apr 06, 2002 at 09:35:25AM +0000, Philip Olson wrote : > > The big question is: how would You (Philip,Yasuo) want list > > to behave when it encounters a hash? Do you want to get the > > keys ? Or the values? Or do you want to get the hashed > > element on its own again as key => value ? > > My opinion is: > $foo = array('a' => 'apple', 'b' => 'banana'); > list($a,$b) = $foo; > print $a; // apple > print $b; // banana > > This would be consistant with how list works with > numerical arrays. It gets the values, not the keys. > > > No, I don't think it's a good idea. That is why we have > > array_(keys|values), it makes the code readable and it's easy > > to understand. > > This is understandable but list() works on values, it does > this for one type of array but not another. > > > For me, it would make most sense to have the following: > > > > list($a, $b) = array('a' => 'apple', b => > > 'beer'); > > > > var_dump($a); > > array(1) { > > ["a"]=> > > string(5) "apple" > > } > > > > I don't think many would share _this_ behaviour. > > > > All in all I think this would get too ambiguous if we would > > change the behaviour. Unless someone comes with really > > intuitive and useable I examples I don't think it should > > change at all (the list construct). > > Aside from saying it works on values for numerical arrays > I can't say much else. That is intuitive and consistant > to me, not ambiguous. It is :) Since we both already have different views. I suggest leaving it; it's not worth the trouble and using the array_(keys|values) is the most readable solution. - Markus -- Please always Cc to me when replying to me on the lists. GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc "Mind if I MFH ?" "What QA did you do on it?" "the usual?" "ah... none :)"

« previous php.dev (#82190) next »