The feature that gives mixed feelings to the author (Re-exporting Imports) is indeed a workaround to this; since each file would externally generate one extra namespacing level, one reexports data structures in order to remove that level.
This is odd, as it's essentially boilerplate by design. Am I missing something?
// Only compile this code if the “foo” Cargo feature is enabled.
#[cfg(feature = "foo")]
pub mod foo;
// Platform-specific stuff, as with std::os.
pub mod os {
#[cfg(windows)]
pub mod windows;
#[cfg(unix)]
pub mod unix;
}
// You can even choose which file to load the module from.
#[cfg_attr(windows, path = "windows/mod.rs")]
#[cfg_attr(unix, path = "unix/mod.rs")]
#[cfg_attr(not(any(windows, unix)), path = "null/mod.rs")]
mod platform_impl;
edit: corrected typo
Whenever I have to touch Go code (for reading and debugging) it's really annoying to just end up going "okay, I've got the folder, now what". Or, even more annoyingly, I've just got an interface and no clue about where to find the implementation.
Of course, that wouldn't be so bad if pls was actually usable and helpful. But at the moment it would be hard to call it either of those things.
Depending on the case, this may have practical implications or not, but architecturally speaking, it's not good form.
A practical side effect is that having a lot of data structures is going to clutter the outline view in the IDE.
That bites me often times. Does gopls help in this regard? Can any tool besides the compiler help me to answer, what methods in a particular piece of code implement what interface?
I do C# for my day job, if I have an interface I put cursor on it and hit a key and go to the definition, whatever file it's in. Another key will cycle the usages of the interface.
This has been solved for years. More recently we've had things like Peek as well.
Usage in Haskell is a bit more mixed, but I see a lot of 'qualified imports'.
I wish I could just split up complex modules into multiple files without the extra namespacing.
The only difference is that content of `{}` following the definition of a module can be read from another file.
You can have a module without a file:
mod foo {
fn function_in_foo() {}
mod bar {
// this is crate::foo::bar module!
}
}
mod foo;
Every file is a module, but not every module is a file.
If `mod foo;` is the only way to make sure a file's code gets compiled, then at some point every file gets its own module, right?
For example `std::time::Duration`, `std::path::Path`, std::cmp::Ordering`. I wish everything was just directly in `std` such as `std::Duration`, `std::Path` and `std::Ordering`.
This re-export that the article talks about is doing this change (which I think is great!) while keeping a nice file structure. I think it is a shame that Rust conflates how you organize your code and how the user of your library sees it by default. However this seems like the best compromise.
Example of this pattern in my code: https://gitlab.com/kevincox/mario-solver/-/blob/137ac5dea067... (however since this isn't a library I use `pub(crate)` instead of `pub`. It works just fine with `pub` except you get a warning if the file doesn't have any exports which is a little annoying).
I don't identify as any of them myself, since I'd be some kind of unclassifiable chimera, but the touch of whimsy warms my heart.
I mean it's an adorable crab! Who wouldn't want to join the rustacean legion behind Ferris. (Who is presumably named after Ferrous[Iron] which 'Rust's)
Why does it make you cringe?
If I met a developer who said they were a gopher or rustacean or whatever. I'd feel physically embarrased for them.
But to be honest, computer people were always more prone to cringey stuff than regular folk... (an extreme example would be the classic clip of Stallman eating dead skin from his feet) It's something with our upbringing I guess.