On Thu, Aug 16, 2012 at 2:39 AM, Lars Schultz <lars.schu...@toolpark.com> wrote:
> Am 16.08.2012 07:55, schrieb Sherif Ramadan:
>
>> Now your array is something completely different from what you wanted.
>> The solution stated earlier is the most sane one (just using
>> array_keys() with a search value).
>
>
> the array_keys solution is slower (although barely) than my suggested
> array_slice solution but comes up short when looking at the result closely.
> The resulting array won't be properly indexed anymore, but will be a
> numbered hashmap. I am not sure wether PHP keeps an internal state on wether
> an array is a map or a classic array, but when you require indizes to be
> sequential (without gaps) then unset() just won't do. Thus it's not always a
> simple problem.
>
Efficiency is only secondary to effectiveness. Either the
function/implementation does what you want or it doesn't.
Further more, your assumption here that the result is incorrect (or
improperly indexed) is completely baseless and moot. You are making a
bold assumption that I both care about the keys and that I expect them
to be numeric and sequential (why can't I have string keys?). This
would also entail that I depend on keys for order (which is not a
requirement for a PHP Array since all PHP Arrays are
ordered-hashmaps).
$array = (99=>1, 7=>2, 701=>3);
foreach ($array as $v) {
echo "$v\n";
}
/* Output is as expected
1
2
3
*/
unset($array[7]);
foreach ($array as $v) {
echo "$v\n";
}
/* Output is still as expected
1
3
*/
The order of the elements in the array has not been affected by the
keys that index them or the use of unset() in the least. So your
argument holds no merit. If you are depending on the sequence of the
keys to determine the order of your elements you made a huge mistake,
because the array was already designed to store elements in order
regardless of whether you provide a key or not. So you're solving the
wrong problem here.
>
>> I don't wish to degrade anyone's contributions to this thread, but
>> this really is the perfect example of making a lot of fuss over
>> nothing on the mailing list and an example of the kinds of discussion
>> we should be avoiding when there are so many other important problems
>> we can solve.
>
>
> Rasmus' suggestion was very concise and unfussy. I've been wondering the
> same thing for some time. It would make the array-functionset more complete
> and code more explicit. Why should we only talk about major changes and
> additions?
>
>
I never said it was redundant or fussy.
Here you're advocating that you're "for" this feature and yet just a
few posts earlier you explicitly state (and I quote):
"I am not arguing for another array-function (as there are so many already)"
This is exactly the kind of noise I see people making in these types
of threads. On one hand they argue indifference (and yet they're here
making all sorts of claims), and on the other hand they want to argue
for arguments sake (like where they're contradicting themselves like
you have).
On one hand you're saying "It would make the array-functionset more
complete" and on the other hand you're also saying "...there are so
many (array functions) already..."
Which is it?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
