这个问题很大程度上是基于观点的,但我认为对于使用 API 编写新包的人来说它可能仍然很有趣expl3
。
expl3
目前定义了几个参数说明符来指示各种函数的参数用法。除了向用户提示预期的参数类型之外,这还给人留下了同一函数支持重载参数的印象,即根据所使用的参数类型,其行为略有不同。
当前支持的说明符是cDefFnNopTvVwx
,即 52 个可能的字母中只有 14 个具有专门的含义。
尤其是在处理自定义数据类型时,n
对实际上属于不同类型(不是从语法角度,而是从语义角度)的各种参数的使用会很快使函数的使用变得比本来应该的更困难。expl3
在我看来,使用超出 API 固定集合的自定义说明符对于更好地区分语义上不同的参数非常有用。
例如,与当前使用的和说明符相比,来自的函数l3regex
将受益于使用r
非编译和R
预编译的正则表达式参数,以更清楚地知道哪个参数是正则表达式以及哪个是需要匹配的标记列表。n
N
目前,我发现引入自定义说明符有两个主要问题:
不同的包迟早会使用相同的说明符来表示不同的类型。我认为这不会是一个大问题,因为通过坚持推荐的命名方案,包名称将包含在每个包函数中,因此用户已经知道在哪个命名空间中定义了所使用的说明符。
使用自定义说明符会破坏当前系统生成新函数变体的功能,因为这需要从“花哨”说明符映射到基说明符
n
和之一N
。提供指定此映射的新 API 函数应该不太难实现,但由于上述问题,可能需要本地化解决方案,因为两个包可能对两个不同的基数使用相同的说明符。
您是否发现使用自定义说明符会导致其他问题?您认为自定义说明符有用吗?还是它们会导致更多问题而不是帮助?