[D7] Rules Collections

@blazas I included that link in the bottom of my post with an explanation of how those errors were false positives. Namely I'm using {@inheritdoc} and that that I'm overloading the underscored name from another module so I cannot change it. I'm not sure I understand about the branch name. It's 7.x-1.x. Am I misreading the page you linked?

@Matters Thanks! fixed it.

@mitchell Thanks for the link. Works like a charm. Committed. And yes it is related to those issues.

In testing those fixed I noticed that Rules now does in fact support lists of lists (could have for some time and I never noticed) so I retract my question about removing the Add Any/All links on Any/All loops.

@blazas, thanks for the clarification but I'm going to go with what mitchell said because that's my understanding from reading the page you linked, but I can change the branch if someone can explain why it has to be changed.

@mitchell, in no particular order:

First, I fixed the label error. Thanks for pointing that out.

I see the patch you meant, now. I'm not sure that it's better. I don't see any way calling the module hooks in a different order would effect the functioning of this particular module. zhangtaihao may be correct that module weights should be deprecated in favor of altering the registry. I don't quite buy the argument, but maybe I would after discussing it. Regardless, I think altering the module weight is something far more Drupal contrib devs are familiar with. I'd rather go with the code more people can understand, all else being equal. Though if the weight causes some issue that I'm not seeing, even potentially, I'll happily make the change. I just don't want to make it artificially harder for others to understand the code just so I can claim having a more elegant solution.

For making an issue on Rules, I'm not really sure what I could tell them other than what I wrote above. I'm not an expert on rules. Everything I know about how it works on the inside was from targeted incursions into its depths to try to figure out what I needed to build this module. The only thing I know for certain is that such changes would be fairly sweeping and would certainly require a new backwards-incompatible version. Even then it wouldn't touch on any more than what would be needed to make this module have less code in it. Maybe it would shine a light on a category of issues, though. Judging by your profile, you seem to have a lot of experience with Rules and its extension modules so any advice would be appreciated, or even just some links to similar issues I could use as templates.

Last but not least, honestly, the major reason was that Drupal modules all have incredibly broad, vague names. Aside from that, time and need permitting, I'd like to add more helpers for dealing with lists (suggestions/code welcome). I don't need it that often but if I can figure out how to do a "Filter" action (an action with a condition for a loop body that returns a second list containing only those items for which the loop body evaluates TRUE). Maybe even just Rules List would be better as Rules has only one kind of collection, though.

@mitchell:

Sorry it took so long to respond but things have been hectic. I'm also sorry that my response became so long but I'm trying to make sure we're on the same page exactly. I used a kind of lazy pseudocode to write any example rules below. I hope it's clear If it's confusing I can rewrite them.

Incompatible with Conditional Rules

I have not used Conditional Rules—though I have come close to needing it a handful of times but a chance to play with it always seem to elude me—so I'm not sure how any/all being plugins (which is necessary for them to function as they do) is incompatible. Do you mean that you can't use any/all as the predicate in its conditionals? That makes sense. In php that would be like doing

if( function($coll){
  for($coll as $k => $v) {
    if( pred($k, $v) ) {
      return TRUE;
   }
   return FALSE;
}($some_collection) ) { 
 do_something($some_collection); 
}

it's just confusing and messy (if that's even legal and not one of php's many strange corner cases :)) and in both cases you'd want to factor that out into a function/rules condition, respectively, if for no other reason than readability. I'd even say that it would probably be MORE awkward to read in Rules UI.

(I'm sure there's some php function on arrays, which I'm not remembering at the moment, that would let you do something similar without an anonymous function, given the function pred, but I'm trying to make a point).

My understanding is also that rules conditionals can only be embedded in action containers and this module's loops are for condition containers.

ANY and ALL are already provided by ConditionalRules

ANY

For ANY you can get equivalent functionality with conditional rules only in the case where you want to check that any item in a list is a particular object, by doing:

ANY item in list:
  item == other_item

. But ANY is far more general and allows you to test for properties of the items, like

ANY item in list:
  item.quantity >= 5

or

ANY item in list:
  item is type 'page'

, to check that any item in the list has a quantity greater than or equal to 5 or that any item in the list is of the page content type. Not to mention since it's a conditions plugin you can check multiple properties (or sets of properties by embedding an OR container in the loop body).

ALL

For ALL you can't do list1 = list2, as you said above, that's not what ALL does. The 'loop body' of ALL is a condition container that runs on the individual items in the list being looped over. ALL evaluates to true only if every single item in the list being looped over causes its loop body to evaluate to true. So

ALL item in list:
  item.quantity >= 5

would be true if EVERY item in the list has a quantity greater than 5 (whereas the version with ANY returns true only if at least one has a quantity greater than 5).

here be dragons

(warning below involves mathematical logic and you can easily skip to next section!)

I assume that by list1 = list2 you meant something like:

if( count($list1) !== count($list2) ) {
  return FALSE;
}
for($i = 0; $i < count($list1); $i++) {
  if($list1[$i] !== $list2[$i]) {
    return FALSE;
  }
}
return TRUE;

You can't do that with all, but you could sort of fudge list1 = list2 by combing any and all

ALL list1_item in list1:
  ANY list2_item in list2:
    list1_item == list2_item

but that wouldn't actually say if list1 = list2, it would say that every item in list2 is in list1 at least once, which isn't equality but a subset relation: list1 ⊆ list2. If list1 were [1, 2, 3, 4] and list2 were [1, 2, 3, 4, 5], the above would evaluate true. You could do

AND
 ALL list1_item in list1:
   ANY list2_item in list2:
     list1_item == list2_item
 ALL list2_item in list2:
   ANY list1_item in list1:
     list1_item == list2_item

which would give list1 ⊆ list2 and list2 ⊆ list1 and you could decide that that meant list1 = list2 but that's set equality which means that if list1 was [1, 2, 3, 4] and list2 was [4, 3, 3, 1, 3, 2, 1] they'd still evaluate true.

Of course I wouldn't recommend doing this as it is HORRIBLY inefficient. If this functionality is needed it would be better to create standard additional rules conditions to test whether list1 ⊆ list2 or list1 = list2, in the set equality sense. I'd be happy to do so if there are any use cases for this, but I can't think of any myself.

Filter

Actually filter seems to be the only thing discussed so far that you could do today with conditional rules, if I understand the module correctly:

Create new list filtered_list
For item in orginal_list: //regular rules loop
  If some_condition(item) then
   add item to filtered_list
  endif
endfor

But I think having a separate filter would be preferable as it would be cleaner to read.

del known shortcomings

The module is complete. I'm just waiting on approval to take it out of sandbox. Is there anything else I could be doing to act on this?

Deleted the -dev branch

I do have a username and id! Fixed.

What is the benefit of using hook_enable vs. hook_install? I've only ever seen it done in hook_install.

The ventral report errors are false positives caused by using {@inheritdoc}, see this bug: https://drupal.org/node/1879768

@kscheirer

The only bad thing that can happen if that code fails is that buttons for adding Any/All show up in before the And/Or buttons so even if it doesn't work no biggie; but it's a simple change and clear, so I've gone ahead and applied it.

@mitchell

Wow, thanks for all that hard work!

I've gone ahead an promoted to a full project and created a beta release which I hope to bump to a full release as soon as a few people try it and make sure there aren't any strange corner cases.

I've renamed the project to Rules List Conditions on the advice of rszrama (and fixed the link/name on the handbook page you made).

In the issue for renaming the module I had a bit of a braindump you may find interesting including some stuff specifically regarding filter: https://drupal.org/node/1980880#comment-7349716

I'll get to those issues you pointed to me as soon as I get a chance; thanks for the links.