Split into more modules and files

[joshlf]

Currently, our source code is organized mostly in a few large modules, and even some of the smaller modules are combined within larger files. At this point, it makes sense to split things up somewhat.

@kupiakos has a proposal for this in f5c5193.

If you're going to take a stab at this, please comment first so that I can suggest a module breakdown to start with. We'll want to start with something very coarse-grained so that it's obviously the right move, and then we can get more fine-grained over time if we decide it's worth it.

[jswrenn]

A rough proposal:

• put conversion related things in pub mod convert
• rename byteorder to num
• pub mod marker for markers, like Unaligned and NoCell
• pub mod gadgets for layout gadgets (e.g., Feature proposal: Layout gadgets. #381)

[joshlf]

A rough proposal:

• put conversion related things in pub mod convert

Presumably FromZeroes, FromBytes, AsBytes?

• rename byteorder to num

I'd push back on this - I think most of the users who need these types probably know about byte order and know that that's what they're looking for. Note that we call out byte order explicitly in the trait docs:

/// `FromZeroes` is ignorant of byte order. For byte order-aware types, see the [`byteorder`] module.

• pub mod marker for markers, like Unaligned and NoCell

+1

• pub mod gadgets for layout gadgets (e.g., Feature proposal: Layout gadgets. #381)

+1 to these going in a dedicated module; name might need bikeshedding.

[kbujari]

Hi, I looked over a lot of the code and would like to try taking this on with some guidance. I assume the end goal would be to keep the module interface the same while splitting the code.

The proposal (f5c5193) keeps the top of the module in the src folder rather than using a mod.rs in the respective folder. For example: src/bytes.rs rather than src/bytes/mod.rs. Is there a preferred method here?

[joshlf]

Hey @kbujari, now isn't a great time for this refactor since we have a lot of outstanding changes that would be affected by a module refactor (ie, it would generate a large amount of rebasing and make PR history hard to follow). It probably makes sense to wait for 0.8.0 to be released - at that point, we'll have fewer changes in flight.