rfc:array_delete
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
rfc:array_delete [2012/08/22 01:38] – [array_udelete] yohgaki | rfc:array_delete [2017/09/22 13:28] (current) – external edit 127.0.0.1 | ||
---|---|---|---|
Line 2: | Line 2: | ||
* Version: 0.5 | * Version: 0.5 | ||
* Date: 2012-08-21 | * Date: 2012-08-21 | ||
- | * Author: | + | * Author: |
- | * Status: | + | * Status: |
* First Published at: http:// | * First Published at: http:// | ||
===== Introduction ===== | ===== Introduction ===== | ||
Line 45: | Line 45: | ||
If the same value occurs more than once in the given array, all occurrences of the given value will be deleted. | If the same value occurs more than once in the given array, all occurrences of the given value will be deleted. | ||
+ | |||
+ | To prevent accidental deletion, $strict defaults to true - note that this differs from array_search() where the most likely objective is to "find something" | ||
Above example is inefficient, | Above example is inefficient, | ||
Line 68: | Line 70: | ||
</ | </ | ||
- | To prevent accidental deletion, $strict defaults to true - note that this differs from array_search() where the most likely objective | + | Note for non internal programmers: |
<code php>int array_delete_recursive(& | <code php>int array_delete_recursive(& | ||
Line 96: | Line 98: | ||
// Delete odd keys | // Delete odd keys | ||
array_udelete($array, | array_udelete($array, | ||
+ | // Delete hash(i.e. string key) | ||
+ | array_udelete($array, | ||
// Delete values with user supplied $value | // Delete values with user supplied $value | ||
Line 132: | Line 136: | ||
If user would like to delete elements, they should use array_walk() rather than array_filter() as it does not delete elements, but creates new array. i.e. Memory and execution is inefficient. Stack overflow and internals thread shows users are not able to choose right API for element deletion. Therefore, array_udelete() is worth to have. | If user would like to delete elements, they should use array_walk() rather than array_filter() as it does not delete elements, but creates new array. i.e. Memory and execution is inefficient. Stack overflow and internals thread shows users are not able to choose right API for element deletion. Therefore, array_udelete() is worth to have. | ||
+ | |||
+ | === Using array_walk to delete elements is undefined behavior === | ||
+ | |||
+ | It says so [[http:// | ||
+ | |||
+ | === Please add this === | ||
+ | |||
+ | I was needing something exactly like this! | ||
+ | |||
+ | == Deleting CURRENTLY working element is OK == | ||
+ | |||
+ | If you are module or core programmer, you should know deleting CURRENTLY working element will not cause any problems as it is NORMAL operation for zend hash. Please ask if you don't understand what we are talking about before edit RFC. | ||
+ | |||
+ | If one reorder element or delete next element to be processed, it will case unwanted behavior. PHP is programming language so shooting your own foot is free for users. | ||
+ | |||
+ | However, this brings up good reason to introduce array_udelete(). array_walk() is certainly not a fool safe function while array_udelete() is. | ||
===== Proposal and Patch ===== | ===== Proposal and Patch ===== | ||
Line 149: | Line 169: | ||
* 0.4 Reverted callable changes. | * 0.4 Reverted callable changes. | ||
* 0.5 Add array_udelete() | * 0.5 Add array_udelete() | ||
+ | * 0.6 Removed anything with `array_walk`. |
rfc/array_delete.1345599534.txt.gz · Last modified: 2017/09/22 13:28 (external edit)