Sane

But you have one function that processes the array. And in that same function, you test whether or not it's a valid item to include. If you want to modify the method of filtering (not the values involved) you need to modify the entire outerworking of the same function that's doing the processing. That's bad coding.

Pass through a static callback function that will determine whether or not its argument is a valid item. The parts of your program that change become isolated from the static parts. Just leave it up to the one who's writing the callback function to worry about how it's being filtered.

If these specifications need to be set dynamically on run-time, according to the user's request, then you can work your way around that. But it's silly to invent your own ASCII logic gates to be interpreted with yet more boolean logic.

With this change you don't need to worry about your own wonky optional parameters. It would make your code capable of being changed in a second flat. The code would be much shorter and clearer. It would also fix your nest of around 11 indents for some of the blocks (horrific!). I suggest you stick to conventional coding unless there's a clear reason why it can not work more efficiently any other way.

As an aside, this very much reminds me of something from over a year ago... I went through almost this exact same situation as you are going through now. I wrote a hash table that would take optional parameters, in its lookup() function, to filter results on a set of logical conditions. I thought I was being clever because it replicated behaviour similar to MySQL, which does use ASCII logic.

But what did not occur to me, is my (brilliant) own logic scheme became absolutely useless as soon as I tried to interface a database client over top. My client could not control the optional parameters that went through, because optional parameters are specified statically on run-time. My method only worked as long as all interfacing to the lookup function was hard-coded.

The reason this logic scheme works for MySQL is because it's not as though their string is parsed into a list of parameters and then passed through a function, and reinterpreted. It's all handled in a very direct way. Presumably with some very clever algorithms too, such as the Horn formula framework. This isn't the only reason your custom approach can fail; it can be plain out difficult to work with, or the requirements of the algorithm can change. In which case you might need to extend the inner portion of your function to be even worse off than it is right now.