Skip to content

Contains behavior is confusing #24

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
epage opened this issue Apr 7, 2018 · 2 comments · Fixed by #35
Closed

Contains behavior is confusing #24

epage opened this issue Apr 7, 2018 · 2 comments · Fixed by #35
Labels
question Uncertainty is involved

Comments

@epage
Copy link
Contributor

epage commented Apr 7, 2018

Currently, the expression hash.contains(5) gets translated to contains(hash).eval(&5). If you understand that context, it makes sense. If you are coming from another language that uses in or contains operators, it gets confusing (the expression 4 < 5 gets translated to: lt(5).eval(&4))

  • Some languages have an in operator. So 5 in hash would naturally translate to in(hash).eval(&5).
  • Some languages flip that and have a contains operator. So hash contains 5 would naturally translate to contains(5).eval(&hash).
@epage epage added the question Uncertainty is involved label Apr 7, 2018
@epage
Copy link
Contributor Author

epage commented Apr 7, 2018

My main interest is I'd like a predicate that is the opposite of the current contains and would like names that help clarify the intent between the two.

@epage
Copy link
Contributor Author

epage commented Apr 7, 2018

On the flip side, hamcrest uses contains for comparing two iterables, weird.

assert_that!(&vec!(1i, 2, 3), contains(vec!(1i, 2)));
assert_that!(&vec!(1i, 2, 3), not(contains(vec!(4i))));

assert_that!(&vec!(1i, 2, 3), contains(vec!(1i, 2, 3)).exactly());
assert_that!(&vec!(1i, 2, 3), not(contains(vec!(1i, 2)).exactly()));

assert_that!(&vec!(1i, 2, 3), contains(vec!(1i, 2)).in_order());
assert_that!(&vec!(1i, 2, 3), not(contains(vec!(1i, 3)).in_order()));

https://github.com/ujh/hamcrest-rust

I'd like to also have iterable predicates but I assume set terminology would be best

epage added a commit to epage/predicates-rs that referenced this issue May 10, 2018
The goal is to make the inention of the functions ore obvious especially
as we add inverses of these.

Fixes assert-rs#24

BREAKING CHANGE: Renamed functions and structs
- `contains` -> `in_iter`
- `contains_hashable` -> `in_hash`
- `ContainsPredicate::ord` -> `ContainsPredicate::sort`
@epage epage closed this as completed in #35 May 10, 2018
epage added a commit to epage/predicates-rs that referenced this issue Sep 27, 2024
chore: Ensure pre-commit gets non-system Python
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Uncertainty is involved
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant