Varargs (*params) instead of iterables in inclusion matchers
Rodrigo Manhães
in current branch (matchers-as-functions), include_all_of,
include_any_of and include_in_any_order matchers expect an iterable as
argument. This causes ugly calls when dealing with literals as the
expected value (at the right side):
[1, 2, 3] |should| include_all_of([2, 3])
[1, 2, 3] |should| include_any_of((5, 4, 3))
It would be much more nicer if I could write
[1, 2, 3] |should| include_all_of(2, 3)
[1, 2, 3] |should| include_any_of(5, 4, 3)
However, this solution would require the use of "starred" (*)
parameters if I'm using variables, and I have a feeling this form is
the most common in real uses:
[1, 2, 3] |should| include_all_of(*options)
[1, 2, 3] |should| include_any_of(*numbers)
Here, we have 3 options:
1) Keep all as is
2) Implement varargs (argument list, starred parameter, whatever...)
3) Accept both (if a list is passed, it is flattened in one level)
I'm in favor of the third option, although I suspect it may have some
side effects.
Opinions?
[]'s
Rodrigo
Hugo Lopes Tavares
This is a new feature, people are not using it yet (and if so, they
know if is experimental).
`include_all_of(2,3)` is cool ;-)
Rodrigo Manhães
> Ignore the first and third option and implement varargs.
> This is a new feature, people are not using it yet (and if so, they
> know if is experimental).
>
> `include_all_of(2,3)` is cool ;-)
Cool, sure!
But I suspect this is not the most frequent use case.
Anyway, i've already implemented it...
Any more opinions?
[]'s
Rodrigo
Rodrigo Manhães
> Ignore the first and third option and implement varargs.
> This is a new feature, people are not using it yet (and if so, they
> know if is experimental).
I'm talking "frequent use cases" not about current uses, but potential
ones. In the expectations I write, I use much more variables than
literals. So, I think this resource may be little useful and to
pollute the most frequent cases by adding a syntax element (the
asterisk).
[]'s
Rodrigo