Module :: mod_interface
Protocol of modularity unifying interface.
Problem Solved
The mod_interface
crate provides a structured approach to modularity, addressing two key challenges in software development:
-
Meaningful Namespace Structuring: The crate enables developers to organize program entities into meaningful namespaces ( read modules ) without additional development overhead. This is achieved through a set of auto-importing rules and a flexible inversion of control mechanism, allowing parent namespaces to delegate control over its items to child namespaces. This approach ensures that each namespace is self-contained and meaningful, promoting better organization and modularity.
-
Enhanced Readability and Tooling Independence: By requiring a
mod private
section that lists all items ( read functions, structures, traits, types ) themod_interface
macro encourages developers to create a concise list of items at the beginning or end of a file. This improves readability, encourages refactoring, and reduces cognitive load by providing a clear, high-level grouping of items. Code tooling is not always reliable and can sometimes be counterproductive by automating tasks that should be done manually to achieve more concise code. While code tooling likerust_analyzer
are useful, this approach minimizes reliance on them, making the program's structure easier to understand and manage.
While some may argue that inversion of control over namespaces may not always achieve the desired outcome, and code tooling can be sufficient, the mod_interface
crate offers a cathartic solution for designing complex systems where tooling and triditional structuring often fall short. By promoting a clear and organized structure, it helps developers grasp the semantics of their programs more holistically.
Example : Trivial
This example demonstrates how to use the mod_interface
crate to organize a Rust program into structured namespaces. The code is divided into a library file (child.rs
) and a main function. The library file defines a module with private functions and uses the mod_interface
macro to specify which functions should be exposed in different namespaces. The main function then tests the visibility and accessibility of these functions.
use mod_interface;
// Define a module named `child`.
// Priave namespaces is necessary.
crate mod_interface!
use mod_interface;
// Define a module named `child`
// Priave namespaces is necessary.
pub use *;
/// Own namespace of the module.
/// Orphan namespace of the module.
/// Exposed namespace of the module.
/// Prelude to use essentials: `use my_module::prelude::*`.
//
Debugging
To debug module interface use directive #![ debug ]
in macro mod_interface
. Let's update the main file of the example :
!
mod_interface
Full sample see at sample directory.
To add to your project
Try out from the repository
Try out from the repository