omeka/Omeka — Issue #149: Actually pass extra filter args as an array
Author: zerocrates
Created: 2012-01-31 19:12:19+00:00
State: open
Labels: Addon API

Right now, a filter can have any number of arguments, but the first one is "special," since it's the one that's actually getting filtered. Everything else that gets passed is usually just an extra option or some context information that *might* be useful to an implementing function.

The result is that both the `apply_filters` calls and the filtering functions often have very long parameter lists, and the only guiding information as to what goes where comes from looking at the documentation.

If we instead we just said that all filters take two arguments: the value to be filtered and an array of options, then:

1. We wouldn't have to keep messing around with the relatively expensive and confusing to read `func_get_args` and `call_user_func_array` calls that are currently needed for every filter call.
2. We wouldn't rely any more on the filtering function to simply pick good names (copying the ones from the documentation) for its arguments to make things clear, since the code calling a filter could assign meaningful string keys for its array of options.
3. We get a little closer to the world of named parameters, so we don't have filtering functions that have signatures containing 7 arguments just because they want the data from the last one.

Of course, the downside of just forcing filters to work this way would be that just about *every* filter and *every* plugin that uses filters would need to be rewritten. We could alternatively just start writing/rewriting filters to use a single "options" array, but it's mighty tempting to be able to rewrite the filter code (and maybe the hook code) to know that every filter has exactly two arguments.

The downsides are pretty extensive, so this has a pretty good chance of not happening, but there's no time like 2.0 to think about the places where things don't really work as well as they might.