Explain in API and README that for cases with both if
and else
clauses, it is better to just avoid these functions
For the pattern object.then_if(condition){ nil }
, this could be used
instead: object.nil_if(condition)
.
This pattern appears when chaining with the “safe navigation operator” (&.). E.g:
Applies the block to the processed element only if the condition is true.
data.map_if(condition){ f(_1) }
would be equivalent to:
Not the same to neither of the following patterns:
map_if
and map
will produce collection of the same
cardinality. filter{}.map{}
or map{}.filter{}
can produce
collection with lower cardinality of map
.
In the same spirit as the other functions of this gem,
data.each_if(condition) { f(_1) }
should be the same as:
It should also support the other forms of each
where it receives
arguments that will be “appended” to the enumerator call, and the form
where it doesn’t receive nor arguments neither block.
In all cases, it should be in a way that “makes sense”.
This one is the easiest to “understand” as it can be read as “make side effect if …”.
../proce.gemspec defines a default to_proc
to all objects. If you
don’t want to add that behaviour to your system, you can use this
proposed method to explicitly as for the default procer propose.
The idea… With procer, you can do:
Because procer defines a default to_proc
method for classes, which
is to compare the class with it’s argument using the “Case Equality
(===
)” operator.
But without procer, this new method, let’s say it is called procer
,
we could do: