module - 在模块(分发？)级别强制执行 API 边界

Question

如何构建 Raku 代码，以便某些符号在我正在编写的库中是公开的，但不对库的用户公开？ (我说“库”是为了避免术语“分发”和“模块”，文档有时会以重叠的方式使用它们。但如果我应该使用更精确的术语，请告诉我。)
我了解如何在单个文件中控制隐私。例如，我可能有一个文件 Foo.rakumod内容如下:

unit module Foo;

sub private($priv) { #`[do internal stuff] }

our sub public($input) is export { #`[ code that calls &private ] }

使用此设置， &public是我图书馆公共(public) API 的一部分，但 &private不是——我可以在 Foo 内调用它，但我的用户不能。
如果 &private，我如何保持这种分离？变得足够大以至于我想将其拆分为自己的文件？如果我搬家 &private进入 Bar.rakumod ，那么我需要给它 our (即包)范围和 export它来自 Bar模块，以便能够 use它来自 Foo .但这样做的方式与我导出 &public 的方式相同来自 Foo将导致我的图书馆的用户能够 use Foo并调用 &private ——正是我试图避免的结果。如何保养 &private的隐私？
(我通过在 META6.json 文件中将 Foo 列为我的 distribution provides 的模块来研究强制隐私。但从文档中，我的理解是 provides 控制着哪些模块包管理器，如 zef 默认安装但执行并没有真正控制代码的隐私。对吗？)
[ 编辑 : 我收到的前几个回复让我想知道我是否遇到了 XY problem 的问题。 .我以为我在问“简单的事情应该是简单的”类别中的一些事情。我正在讨论从 Rust 背景强制执行 API 边界的问题，其中 common practice是在 crate 中公开模块(或仅对它们的父模块)——这就是我问的 X。但是，如果有更好/不同的方式在 Raku 中强制执行 API 边界，我也会对该解决方案感兴趣(因为这是我真正关心的 Y)]

Answer 1

I will need to give it our (i.e., package) scope and export it from the Bar module

第一步不是必须的。 export机制同样适用于词法范围 sub s 也是，这意味着它们仅可用于导入它们的模块。由于没有隐式重新导出，模块用户必须显式使用包含实现细节的模块才能让它们触手可及。 (顺便说一句，就我个人而言，我几乎从不在我的模块中使用 our 范围作为 subs，并且完全依赖于导出。但是，我明白为什么人们也可能决定以完全限定的名称提供它们。)
也可以对内部事物使用导出标签( is export(:INTERNAL) ，然后是 use My::Module::Internals :INTERNAL )，以向模块用户提供更强有力的提示，即他们正在使保修失效。归根结底，无论语言提供什么，有足够决心重用内部结构的人都会找到一种方法(即使它是从您的模块中复制粘贴)。一般来说，Raku 的设计重点是让人们更容易做正确的事情，而不是让他们不可能“错误”地做事，因为有时错误的事情仍然比其他选择错误更少.