[wp-hackers] apply_filters, merge_filters and reset()

[Jacob]

Hmm, I believe my usage of foreach was to use the $value of the first 
foreach (since it is the array) instead of doing your method. I was able 
to confirm that, at the very least, it doesn't break anything on the 
trunk. I would rather use foreach than while since it looks cleaner.

If you want to take care of 2.3.x, I'll submit a patch for 2.4. There 
are some other areas I want to clean up in the trunk.

Travis Snoozy wrote:
> On Thu, 08 Nov 2007 08:12:16 -0600, Jacob <wordpress at santosj.name>
> wrote:
>
> Two separate issues have been confused and slurred together here -- let
> me try and separate them back out.
>
>
> 1) In all cases, the array being worked on needs to be completely
> iterated over. Using next() requires that reset() be called prior to
> the start of iteration. Reset() is not always being called on
> $wp_filter[$tag] in apply_filters. This seems wrong. This is my
> original issue/question. My proposed solution to *this* problem is to
> add an appropriate reset() call to each of apply_filters, do_action, and
> do_action_ref_array.
>
>
>
> The reason I came across the above, but NOT actually part of the
> question, is the fact that I would like to use foreach as a
> replacement. Since we have discussed it thus far, though, these are my
> thoughts on this completely separate suggestion:
>
>
> 2) Foreach iterates over a copy of the array, while next et. al. iterate
> over the array directly. Updates to the array inside the loop are only
> reflected when working directly on the array in question. I understand
> and do not contest this.
>
> 3) Using foreach over next would be beneficial for a number of reasons
> (automatic, full iteration; more readable; faster).
>
> 4) The problem you described re. adding callbacks to the
> currently-running filter/action is completely moot, because the current
> implementation *already uses* foreach on the inner loop (where the
> installed callbacks exist). The while(next(...)) construct is used to
> iterate over priority levels only -- all that needs to be done to
> support foreach for priority levels is to define indexes 1-10 in the
> $wp_filters["$tag"] array when the $tag index is first created.
>
> Removing a callback on a hook, while in a callback being invoked by the
> same hook, is not a guaranteed operation -- unless the callback being
> removed is in a later-run priority level. Adding a callback on a hook,
> while in a callback being invoked by the same hook, is pointless --
> unless (again) the callback is being added to a later-run priority
> level (otherwise, you may as well just call the other callback
> directly). The semantics of the current implementation do not allow
> either of these scenarios, which is as it should be.
>
> The foreach loop for handling each priority level is nested, and so the
> updated data in later priority levels can be accessed directly. Here is
> an example re-implementation using a foreach on the outer loop:
>
> $wp_filter["foo"][1][] = "This is the first item in runlevel 1.\n";
> $wp_filter["foo"][2][] = "This is the first item in runlevel 2.\n";
>
>
> foreach($wp_filter["foo"] as $key => $value) {
>     foreach($wp_filter["foo"][$key] as $item) {
>         echo $item;
>         $wp_filter["foo"][2][] = "This item was added to runlevel 2 in
> both runlevels 1 and 2, but only the one from level 1 will show
> up.\n";
>         $wp_filters["foo"][3][] = "Won't work, but if we had
> pre-defined this index before the outer loop, it would be fine.\n";
>     }
> }
>
> [Output]
> This is the first item in runlevel 1.
> This is the first item in runlevel 2.
> This item was added to runlevel 2 in both runlevels 1 and 2, but only
> the one from level 1 will show up.
> [/Output]
>
>
>   


-- 

Jacob Santos

http://www.santosj.name - blog
http://wordpress.svn.dragonu.net/unittest/ - unofficial WP unit test suite.

Also known as darkdragon and santosj on WP trac.