PSC本周动态（236） | 2026-09-22
内容提要
核心团队讨论了“match case”提案，认为意图不同，需继续在邮件列表讨论。@INC目录的PrePPC可推进为完整PPC，尤其需明确非UNIX系统细节。团队希望先统一“核心功能挂钩”概念及%{^HOOKS}哈希，再考虑可替换随机数生成器，并需先审视rand()接口限制。
延伸解读
“match case”提案的现状与分歧
核心团队认为两个“match case”提案意图不同，并非简单替代关系。解构概念虽好但需进一步讨论，目前决定在邮件列表继续。这表明提案尚未成熟，读者应关注后续邮件列表的讨论进展，而非期待短期内有明确结论。
@INC目录PrePPC的推进方向
关于@INC目录的PrePPC被认为足够好，可推进为完整PPC文档以讨论细节，特别是非UNIX操作系统的具体问题。这意味着该提案进入更正式阶段，但跨平台细节仍是关键挑战，读者需留意后续对非UNIX系统支持的明确说明。
核心功能挂钩概念的优先性
团队希望先统一“核心功能挂钩”概念，可能涉及%{^HOOKS}哈希，再考虑可替换随机数生成器。例如，$SIG{__WARN__}和$SIG{__DIE__}是否属于此范畴。这显示挂钩机制是更基础的问题，读者应关注概念统一后的设计，而非急于讨论随机数生成器替换。
rand()接口限制需先行审视
在提供随机数据生成挂钩前，团队认为Perl的rand()和srand()函数接口本身可能限制良好行为。因此，需先审视这些接口，而非直接替换更好的随机源。这提示随机数生成器的改进可能涉及接口调整，读者需注意后续对rand()限制的分析。
Q&A
PSC对“match case”提案的讨论结果是什么？
核心团队认为两个“match case”提案意图不同，不能简单互相替代。解构概念原则上不错，但需要进一步讨论。目前决定让讨论在邮件列表上继续。
@INC目录的PrePPC下一步会怎么处理？
关于@INC目录的PrePPC被认为足够好，可以推进为完整的PPC文档，以便进一步讨论细节，特别是非UNIX操作系统的具体问题。
PSC在考虑可替换随机数生成器之前想先做什么？
团队希望先为“核心功能挂钩”找到更一致的概念，可能特别是%{^HOOKS}哈希，然后再考虑可替换随机数生成器。例如，需要确定$SIG{__WARN__}和$SIG{__DIE__}是否属于这里。
为什么Perl的rand()接口可能阻碍获得更好的随机性？
因为Perl提供的rand()（和srand()）函数接口本身可能限制获得良好行为，在简单替换更好的随机源之前可能需要先研究这个问题。
PSC本周会议讨论了哪些主要议题？
会议讨论了“match case”提案、@INC目录的PrePPC、核心功能挂钩概念（包括%{^HOOKS}哈希）以及可替换随机数生成器，并特别关注了rand()接口的限制。
关于“核心功能挂钩”，PSC提到了哪些具体问题？
PSC希望找到更一致的概念，可能涉及%{^HOOKS}哈希，并质疑$SIG{__WARN__}和$SIG{__DIE__}是否应包含在内。
