[Feature Request] Module-Private Members in KCL

[suin]

Feature Request

Is your feature request related to a problem? Please describe: KCL currently lacks a built-in mechanism for module-private members, which can lead to difficulties in encapsulation and code organization. Without private members, it's challenging to hide implementation details within a module, potentially leading to tighter coupling between different parts of a codebase and making refactoring more difficult.

Describe the feature you'd like: I propose adding module-private members to KCL. This feature would allow developers to declare certain elements (variables, types, schemas, etc.) as private to a module, restricting their visibility and access to within the module they are defined in. For example:

private a = 1  # This variable is only accessible within the current module

private type InternalType = str  # This type alias is only accessible within the current module

private schema InternalConfig:
    # This schema is only accessible within the current module

schema PublicInterface:
    # This schema is accessible from other modules

Describe alternatives you've considered:

1. Using naming conventions (e.g., prefixing with underscore) to indicate private members, similar to Python.
2. Implementing a linter or static analysis tool to enforce access restrictions without language-level support.

Teachability, Documentation, Adoption, Migration Strategy: Module-private members could be introduced as a new language feature with clear documentation and examples. Scenarios where this feature would be helpful include:

1. Large-scale projects where clear API boundaries are crucial.
2. Library development, allowing authors to hide internal implementation details.
3. Refactoring existing codebases to improve encapsulation.

Migration strategy:

1. Update KCL style guides and best practices to incorporate the use of private members.

Documentation would include:

• Syntax and usage guidelines
• Best practices for when to use private members
• Examples of refactoring patterns to leverage private members
• Comparison with public members and impact on module design

This feature would align KCL more closely with other modern programming languages that support strong encapsulation, potentially making it more attractive to developers familiar with such concepts.