Dear all,
Recently a project i have been working on took a sharp turn. Long story short, instead of having one big code stack everything is now being broken into small single object crates. I cannot say i have a lot of experience with project design so my questions are mostly about why would this strategy be beneficial / not.
First I was wondering what you think about this divide-et-impera approach. Is this really where future projects ought to thrive toward?
One reason why this was implemented is because different contributors were not so eager to share particular parts with others due to "security" reasons. And apparently now when they can restrict certain functionalities there will be no unintended use of different parts of code and will be "safer" to redistribute. I do not understand how this is so? Is it possible that if I have two objects in my lib that share a common trait, if i use only one object in my app via shared trait that somehow the other can be exploited as well?
Given everything gets broken into small pieces I see not utility for the traits at the level of crate anymore aside from segregating access to different parts. Is my assumption wrong? What i mean is to basically have a dummy struct and then multiple different methods inside each clustered according to differnt traits. Example (would this even made sense to do ?)
pub struct X;
pub trait A {
fn x ()-> Result<>;
}
pub trait B {
fn y ()-> Result<>;
}
impl A for X{
pub fn x()-> Result<>{}
}
impl B for X{
pub fn xy)-> Result<>{}
}
// then in appA i just call trait A and in appB triait B. (Though i believe I would be asked to break this up into two crates at some point )
Which design is easier to maintain long term ?
Sorry for the vague questions and i do understand that I probably am asking something dumb here, but I am having hard time understanding this myself and would like to hear other opinions regarding advantages/caveats on the above points (nothing lengthy because i know you all have much better things to do then to write essays here )
Also I really appreciate examples. To me code is like a picture , short example is worth a thousand words.
As with many other questions of code organization, there are very few general rules that apply to all situations. “Use many crates” certainly isn't one of them.
Dividing projects into many crates can create the opportunity for compilation performance improvements, but each additional crate has its own overhead, so it makes sense only once you have fairly large crates, and when you can anticipate or measure an actual improvement (perhaps with use of the build timings report).
By using multiple crates rather than single crates, you lose the benefit of dead-code analysis (anything publicly exported can't be detected as unused), and you will encounter more cases of orphan rule restrictions on trait implementations.
Not as much optimization is possible across crates, unless you use link-time optimization (LTO), which slows down compilation overall (though it might be a net benefit).
One reason why this was implemented is because different contributors were not so eager to share particular parts with others due to "security" reasons.
Security is always relative to some threat model. What are they defending against? Don't confuse modularity/encapsulation/loose-coupling, software engineering practices to help make programs easier to maintain, with security, protection against some form of attack by adversaries.
Your description is so vague that it's hard to tell what policy is actually being proposed, and thus hard to comment on the advantages or disadvantages of it.
Though concise you put a lot of leads in your comments. I apologize for the vagueness. As a small time developer vagueness comes with the territory. I was just wondering why would anyone bother with traits if the crate contains only one very precisely defined object. Do i get anything pa exposing a particular method of that object via trait given it, on its own has not use for the trait (or at least not by my understanding of how traits work). And whether it is a common practice to break a large project into a set of independent crates.