rfc:iteration-tools

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
rfc:iteration-tools [2008/11/03 15:03] amenthesrfc:iteration-tools [2017/09/22 13:28] (current) – external edit 127.0.0.1
Line 27: Line 27:
 ==== Why do we need tools for iteration ==== ==== Why do we need tools for iteration ====
  
-Given that iteration is such a recurrent situation and conforming to the DRY principle, but also in total respect with common sense, an abstraction is required. Thankfully, patterns regarding iteration were observed almost fourty years ago by some very smart people. These people found out that iterative processes can be abstracted away in a handful of functions.+Given that iteration is such a recurrent situation and conforming to the DRY principle, but also in total respect with common sense, an abstraction is required. Thankfully, patterns regarding iteration were observed almost forty years ago by some very smart people. These people found out that iterative processes can be abstracted away in a handful of functions.
 For example: For example:
     * some of the functions modify data in the set     * some of the functions modify data in the set
Line 44: Line 44:
 While these classes do their job they have some shortcomings: While these classes do their job they have some shortcomings:
     * They only iterate over Traversables. Supporting arrays would be nice (Indeed, we have array_map(), array_walk() and some other similar functions for array processing, yet, I think we should unify these similar tools. Not to mention that array_* functions do not adhere to some param order standard.     * They only iterate over Traversables. Supporting arrays would be nice (Indeed, we have array_map(), array_walk() and some other similar functions for array processing, yet, I think we should unify these similar tools. Not to mention that array_* functions do not adhere to some param order standard.
-    * FilterIterator, RecursiveFilterIterator and SearchIterator require declaration of an aditional classes that extend them+    * FilterIterator, RecursiveFilterIterator and SearchIterator require declaration of an additional classes that extend them
     * CallbackFilterIterator, although I haven't had the chance to use it, it misses one important thing. It's not passing the iterator itself as a third parameter to the callback.     * CallbackFilterIterator, although I haven't had the chance to use it, it misses one important thing. It's not passing the iterator itself as a third parameter to the callback.
  
Line 147: Line 147:
 </code> </code>
  
-While the 1.2 example is very similar to 2.1 it differs from it in that it's not passing the iterator to the callback function and, of course, the fact that I use a function instead of an object. Another difference is that present implementation of CallbackFilterIterator (as documented on http://www.php.net/~helly/php/ext/spl/) may also be used as a virtual CallbackMapIterator. For example, it's not only filtering the elements of the iterator into a new iterator, but it MAY also change those values. In my proposal, the function that changes values is map() which translates a certain value to another depending on the callback function. filter() only keeps items that validate agains certain criteria inside the callback function. I believe a clear distinction between these features must be reflected in the API, thus two different functions in my proposal.+While the 1.2 example is very similar to 2.1 it differs from it in that it's not passing the iterator to the callback function and, of course, the fact that I use a function instead of an object. Another difference is that present implementation of CallbackFilterIterator (as documented on http://www.php.net/~helly/php/ext/spl/) may also be used as a virtual CallbackMapIterator. For example, it's not only filtering the elements of the iterator into a new iterator, but it MAY also change those values. In my proposal, the function that changes values is map() which translates a certain value to another depending on the callback function. filter() only keeps items that validate against certain criteria inside the callback function. I believe a clear distinction between these features must be reflected in the API, thus two different functions in my proposal.
  
-=====Some aditional benefits=====+=====Some additional benefits=====
 As you have seen, my proposal includes a function called walk() which does exactly the same thing as a foreach construct. The real useful thing this function provides is the ability to mimic scope inside a foreach block. So, for example: As you have seen, my proposal includes a function called walk() which does exactly the same thing as a foreach construct. The real useful thing this function provides is the ability to mimic scope inside a foreach block. So, for example:
  
Line 192: Line 192:
 Python: Python:
     * http://www.python.org/doc/2.5.2/tut/node7.html#SECTION007130000000000000000     * http://www.python.org/doc/2.5.2/tut/node7.html#SECTION007130000000000000000
-    * http://www.python.org/doc/2.5.2/lib/itertools-functions.html (these Python package differs quite much from what I have proposed, nevertheles we may extract other useful things from there too)+    * http://www.python.org/doc/2.5.2/lib/itertools-functions.html (this Python package differs quite much from what I have proposed, nevertheless we may extract other useful things from there too)
  
rfc/iteration-tools.1225724618.txt.gz · Last modified: 2017/09/22 13:28 (external edit)