refactor tests and impls into distinct modules

[chris-ha458]

I first started by moving all tests to tests/tests.rs
This was to ensure maximum isolation to see what kind of testing and usage is possible without access to private details.

Then, for any tests that do not compile, I moved them into a separate file called src/unit_tests.rs
This allowed for a more cleaner separation imports as well.

Feel free to comment on any aspects of this PR including separation of integration tests and unit tests, filenames or paths, or if you feel like any tests were misplaced(should be in integration but included in unit or vice versa).
I recognize that a lot of this would be a stylistic choice and I am not strongly tied to the current organisation.

When we find an acceptable organisation, I can proceed to further refactor by separating some traits from lib.rs into a separate traits.rs or counter.rs (if this is indeed something you'd be willing to see in the first place)

[coriolinus]

Interesting start, and a good idea in principle.

With regard to further splitting out impls, I'd propose an organization like this:

• src/impls/index.rs: Index, IndexMut
• src/impls/add.rs: Add, AddAssign
• src/impls/intersection.rs: BitAnd, BitAndAssign
• src/impls/union.rs: BitOr, BitOrAssign
• and so on

[chris-ha458]

Since i've reflected all changes (except the lint related one) and tests are running again I'll try the splitting out impls, one by one.

[chris-ha458]

so now the add{_iterable,_self} sub{_iterable,_self} index intersection union are separated but many are still left.

From here I could think of
init.rs or create.rs where the new,default or other impl that create new Counters.

[coriolinus]

My instinct for now is to leave all the impl Counter blocks in lib.rs. If we can find a place where there are two blocks with identical bounds, we could unify those, but I want to see how big lib.rs is with the trait implementations factored out before deciding to break up the core item implementations.

You've seen the pattern, as far as splitting up the trait implementations. Just focus on the semantics of the operations, and make a module for each. I'll look it over when I have the chance, and comment if I see something I don't like.

[chris-ha458]

I think even deref.rs might have gone too far.
Also i don't think i haven't seen any blocks with identical bounds.

[chris-ha458]

I would like to move some impl Counter that creates new counters into create.rs. But i tried to stay within your instinct

[coriolinus]

deref.rs is fine for me. Stays consistent.

What if instead of a single create.rs, there was a from_iterator.rs handling that case, and a new.rs handling creation of new empty counters (including Default)? That way, the module is handling only a single modality of creation.

[coriolinus]

I'm happy with this. The module structure looks much more balanced now:

$ fd -g '*.rs' -x wc -l | sort -rn
Tue 29 Aug 2023 03:44:11 PM CEST
599 ./src/lib.rs
235 ./src/unit_tests.rs
186 ./tests/tests.rs
91 ./src/impls/index.rs
84 ./src/impls/union.rs
82 ./src/impls/sub_self.rs
77 ./src/impls/into_iterator.rs
77 ./src/impls/extend.rs
74 ./src/impls/from_iterator.rs
71 ./src/impls/intersection.rs
62 ./src/impls/add_self.rs
57 ./src/impls/sub_iterable.rs
55 ./src/impls/add_iterable.rs
33 ./src/impls/create.rs
26 ./src/impls/deref.rs
12 ./src/impls.rs

There's one more change that might reasonably fit into this pr: externalize the module documentation. That would subtract almost 300 lines from lib.rs. However, I am ambivalent about it; you can choose to make that change, or not.

[chris-ha458]

If all else is well, lets merge for now.
I'll look into 1990-external-doc-attribute that you've linked. Depending on the perceived difficulty/necessity, I will do that or bench with criterion next.