Consider a more semantic module name?

I went into this somewhat in the issue queue applying for full module status: last paragraph of https://drupal.org/node/1968118#comment-7304968

I do agree that it needs a better name, and so far "Rules List Conditions" is the forerunner (so thanks for that! (and Commerce!)) but then if I added more declarative/functional helpers like filter, mentioned in the linked comment above, then the name is wrong. Maybe I should rename it to Rules Lists Conditions and if I ever do filter put that in a "Rules List Actions" module . . . (of course then if they shared any code I'd be sad about the duplication)

I'm going to need to think about the scope of this module before I change the name. Right now I am leaning to calling it feature complete and going with Rules List Conditions, though.

I don't know if that's any less abstract and you have to know what constitutes a rules plugin, which I certainly didn't until I got sick enough of hacking awkwardly around this gap to write this module and had to dig around the rules code base.

I'm thinking out loud here: I'd guess the candidates for additional plugins and such would be the usual higher order functions from functional programming: map, filter, fold (left and right), zip, and stuff like groupby and length and min and max.

Rules' reference semantics make its standard for-each loop map for all intents and purposes.

Filter could be useful if you want to act on some of the items of a list, that meet a particular criterion or set of criteria, so that's a maybe. The confusing part would be that it would be an action but its 'loop body' would be a condition container, and there's no precedent for that.

foldl and foldr might conceivably have a use though the only one I could possibly think of would be to sum a list. I just don't see it coming up enough to warrant the complexity of implementing them.

I see no use whatsoever for zip in Rules.

Groupby could be very useful: take a list and a property/field to partition it and in its loop body have a $value_grouped_by and a $subset_of_list_being_looped_over. But that would be inordinately complex and tricky to work out how to integrate that into rules and implement it. It could help with multistores where you want to divvy payment up by store owner, something like "group line items by line-item.referenced-product.owner" and then in the loop body you have an $owner and a $list_of_orders_line_items_but_just_those_that_belong_to_said_owner

Length I don't see being very useful in general and I'm sure that's already implemented somewhere else, maybe even in Rules core.

Min and Max could be useful as actions if they took a list and a property/field to compare and returned the min or max. Would be neat to have something like:

IF order.total > $100
THEN
 cheapest := min item of order.items by price
 cheapest.price = 0

(of course the real logic would be more complicated because that makes a million dollar order free if you're just ordering one thing a lot of times). Those could probably just be regular ole plain jane rules actions.

So the only candidates are, in order of difficulty (and perhaps in reverse order of usefulness simultaneously), min/max, filter, and group by.

Aside from actually adding new kinds of collections to rules, which I don't see being terribly useful) that's as much as I can see ever being in the scope of this module. Maybe I left something out, though. Any thoughts? I left out things like sorting and reversing a list and so on because I don't see any need for that within Rules.

It looks like all of those would be actions (even though filter would take a condition container, which maybe wouldn't be as confusing as I fear) so maybe Rules List Conditions/Rules List Actions would be a good split.

I have changed the name to rules_list_conditions

Bit more info.