0

im trying to refactor this code of mine:

test_cases.select{ |x| x.script && x.script.versions && !x.script.versions.empty? }

and use the andand gem. Basic usage just tells us that we substitute andand to the &&(thus the name) so i tried this:

test_cases.select{ |x| !x.andand.script.andand.script_versions.andand.empty? }

but it seems it is NOT-ing the whole statement(i just realized this now while writing the question)

Does this mean I have to separate the empty? clause? Is there an andand function that checks for not(but only the last one?)

corroded
  • 21,406
  • 19
  • 83
  • 132

3 Answers3

0

You could always do

test_cases.select{ |x| x.andand.script.andand.script_version } unless x.empty?

On the topic of andand: while we use it in our project and I generally quite like it, I found that spurious use of andand can hide problems that should be properly addressed. Like many good tools it has to be used with caution.

Michael Kohl
  • 66,324
  • 14
  • 138
  • 158
0

I actually used this clause and it works:

test_cases.map{ |x| x.script.andand.versions && !x.script.versions.empty? }.none?

only one andand call and used map instead of select

corroded
  • 21,406
  • 19
  • 83
  • 132
0

When x is not nil it works well, I guess. The problem is when x is nil because ...empty? returns also nil, and !nil -> true. Then this x is wrongly selected. I'd propose an explicit check of the boolean value:

 test_cases.select { |x| x.andand.script.andand.versions.andand.empty? == false }

Or probably better use blank/present without a last andand:

 test_cases.select { |x| x.andand.script.andand.versions.present? }
 test_cases.reject { |x| x.andand.script.andand.versions.blank? }

Note: it's not related with the problem here, but I prefer Ick's maybe over andand, as only nil is treated as "void" (false is a legitimate value which I think should not be proxied).

tokland
  • 66,169
  • 13
  • 144
  • 170