Hierarchy practice suggestion: Dir basis module

[younggam]

Hi, I want to suggest some way to organize modules in rust.

Let's cut to the chase.

methodology of Dir basis module (I named it with random words came to mind.)

1. When you make module with folder(subDir), use module/mod.rs way only.
2. Leave codes in lib.rs and mod.rs only about module declaration and re-exporting.
3. each lib.rs and mod.rs always re-exports sub-module's all sub-module
   ex)

/structs
    -mod.rs
    -foo.rs
    -bar.rs

and in mod.rs

mod foo;
pub use foo::*;
mod vertex;
pub use vertex::*;

So.. what happens?
1.you can use folders(dirs) as module-path and files(.rs) as Structs
in absolute path.
ex) with example above, and foo.rs has Foo and bar.rs has Bar

main(){
    let foo=crate::structs::foo;
}

2. relative path(super: cannot access higher folder(dir)

What is good?

1. intuitive and familiar. If you want use struct in dir of src/structs/foo/bar.rs, you just use crate::structs::foo::Bar;
   and this is very similar in java-package system.

2. role of mod.rs and some-other-name.rs is separated.

What is bad?

1. doesn't use rust's rich modular things
2. useless code duplicating

[Ideator]

Not sure why'd ever want to have such a system, honestly - modules don't just define struct-s, they can contain functions as well. How would those be more usable using this system?

I (virtually) never rely on mod.rs inside folders myself. Often sub-modules get called using just a few letters and mixing those up visually with mod.rs (which doesn't stand out that much in terms of being just a placeholder for the structure of the module itself) when scanning the content of the folder later serve as nothing but an annoyance factor. If there was a way to rename it to _mod.rs or just _.rs - I think I'd use it much more often that I do (is there a way to do that, by the way? - happy to hear it).

[Michael-F-Bryan]

I agree with points 1 and 2, but don't agree with the rest.

You should be using namespaces and modules in order to organise your code logically, not blindly following a single convention. Always re-exporting the contents of every submodule will just pollute your namespaces with unnecessary implementation details and make it hard to give end users a well-curated public API.

@younggam

this is very similar in java-package system

Keep in mind that "intuitive" and "familiar" for someone used to Java's packaging conventions is very different from what you might be used to if you have a Rust or Python background.

I personally think putting all structs under a specific structs namespace is silly... It's kinda like how people using MVC might split things up into models/, views/, and controllers/ folders instead of something that reflects the app's structure like login/, dashboard/, and settings/. You want to keep coupled things close together and unrelated things separate.

[Heliozoa]

I think this is just a suggestion for using the current system, not an idea for any kind of reworking.

That said, there are a couple of things in the post that make it hard to comment on. For example, you can't use a struct like this unless its name is in lowercase: let foo=crate::structs::foo;, and if everything is re-exported you can just use crate::Bar instead of typing up the exact path to bar.rs.

[skysch]

Oh yeah, you're right. I totally misread this...

[kornel]

Are you aware of the inline mod syntax?

You don't have to have a file called structs.rs or structs/mod.rs. You can make the module inline in lib.rs:

mod structs {
   mod foo; // reads structs/foo.rs
   mod bar; // reads structs/bar.rs
}