2000年5月7日这周在p5p
备注
您可以订阅此摘要的电子邮件版本，方法是将空消息发送到[email protected]。
请将更正和补充发送到[email protected]，其中YYYYMM是当前年份和月份。
审查即将到来
正如我几周前提到的，Sarathy在3月份提出了一种轻量级审查方案，这是在一系列大型争执之后，导致几位重要人士离开列表。
关于Damian Conway的过度加载模块（见下文）的讨论引发了对这个话题的回归。
这非常重要，您一定要阅读Sarathy的实际提案以了解详情。提案。
Sarathy说，上次他提到这一点时，他收到了一些建议，以下人员应担任裁判：
- Nathan Torkington
- Kurt Starsinic
- Chip Salzenberg
- Mark-Jason Dominus
- Simon Cozens
- Damian Conway
- Russ Allbery
然后他问这些人是否愿意担任裁判。据我所知，迄今为止，只有Simon和我接受了。
还讨论了一些关于裁判技术的细节，看起来这将发生。
Simon的p5p指南
在这个过程中，Simon发布了他撰写的一份关于如何使用p5p的文档。
关于perldoc和索引的深入讨论
本周350条消息中有48%与perldoc以某种方式相关。
讨论始于Johan Vromans建议将perldoc扩展到对perldoc -f foreach执行合理的操作，类似于目前对待perldoc -f print的方式。Sarathy同意这一点；Tom Christiansen强烈反对。我认为Tom反对的要点是，简单地grep整个手册以查找想要的术语非常容易，即使在非Unix的残次品平台上，grep也可以实现为一个单行Perl程序，而且应该鼓励人们了解他们自己的搜索手册的能力，而不是鼓励他们依赖像perldoc这样的现成解决方案。我认为这一点有可取之处，但Tom似乎没有在其他的p5pers中获得太多同意。
由此产生了几个有趣的话题。首先，Tom宣布他正在编写一份新的手册页，perlrtfm，将解释手册的组织方式和如何有效地使用它。
伊利亚说，将关键词映射到手册章节不应该硬编码到perldoc中，而应该放在某个索引文件中。尼克·英格-西蒙斯同意了，我也一直这么认为。grep非常不错，在大多数情况下都工作得很好，但就像几乎任何使用过网络搜索引擎的用户都能告诉你的那样，有时你正在寻找的文档并不包含它应该包含的关键词。我去寻找这个例子，很快就找到了一个：如果你想找到除法的余数，并用grep搜索remainder，你不会在perlop中找到关于模运算符的章节。一个结构良好的索引可以解决这个问题。
汤姆指出，构建和维护一个索引将是一项巨大的工作量。
伊利亚谈到了IBM-Book格式的Perl在OS/2上的文档，该文档有一个命令可以在文档上执行全文搜索并返回最佳匹配。
马蒂亚斯·尼尔阿赫说，“shuck”，Macintosh文档浏览器，使用了索引，如果索引数据一开始就更好，它将工作得更好。
索引项目需要一个倡导者和一群志愿者。如果你对这两个职位感兴趣，给我发个信息，我会尽量把感兴趣的各方联系起来。
X<>
Pod一直记录了一个X<>标签“用于索引”。但文档从未说明它的工作方式或内容的格式，而且它从未真正使用过。在5.6版本中，它在整个文档集中恰好出现了两次，而X<>的文档只说
X<index> An index entry
汤姆说，如果构建了索引，应该使用X<>标签来标记具有索引条目的pods。我指出，这样做的缺点是，如果有许多X<>标签，它们会使pods文本本身更难以阅读。但我认为没有人提出了更好的建议。我根据我（有限的）索引经验发送了一些关于X<>可能语义的邮件。（其中之一是我正在写一本关于Pod-like标记语言的Perl的书，我正在使用X<>来表示索引条目。）
汤姆还指出
=for index
可以用来指示下面的文本块是一系列索引条目。
splitpod
一个几乎无人知晓的软件类别中的条目：在Perl pod目录中有一个名为splitpod的程序，可以将单个pod文件拆分成多个文件。例如：
splitpod perlfunc.pod
创建了许多名为abs.pod、accept.pod、…、y.pod的pod文件。然后你可以分别使用pod2man或其他方式。
别名
伊利亚建议Pod支持一个别名指令来定义一个与某些其他转义序列等效的新转义序列。例如
=for macro B <= Y
使Y<some text>与B<some text>同义。这样，你可以使用Y来指示粗体无衬线文本（例如），但标准转换器如pod2text仍然知道如何将其渲染为与B<...>相同。
perldoc愿望清单
本·蒂利的Perl文档愿望列表，包括perldoc的输出应包括找到文档的文件名。这将有助于提醒人们，文档实际上位于某个文件中，并不仅限于perldoc魔法精灵。
Tom的计划
当人们都在提出各种增强perldoc的想法时，汤姆·克里斯蒂安森提出了他自己的想法，以解决Perl文档的一些更深层的基本问题
汤姆：首先，大幅重新组织文档，大致沿着萨拉蒂暗示的路线：参考、教程、内部。
其次，将整个perldoc代码丢弃，从头开始使用一个真正的设计规范，不要疯狂地偏离其目的。
第三，提供真实工具来处理不相关的事情，比如识别Perl在哪里找到其标准模块路径。模块需要工具。
他还演示了一些可能替代庞大笨重的 perldoc 的简单工具。
汤姆后来还指出，与 perldoc 不同，这些工具不需要以非常简单和原始的方式解析 Pod。布拉德·艾普尔顿提出，Pod::Select 模块会进行类似的解析，而汤姆回答说，它对生成文档完全没有用，因为它的速度比原始方法慢五十到一百倍，没有人愿意使用一个需要十秒钟才能生成文档的文档程序。
布拉德表示，可以将 Pod::Parser 优化得更快，但我怀疑它是否真的能足够快。在我的测试中，汤姆的小型脚本比 Pod::Select 快了 185 倍。布拉德也请求帮助；有兴趣加速 Pod::Parser 的人应该联系他。
布拉德还请求帮助扩展这些模块的测试套件。
编辑意见部分
这样的讨论让我认为 Pod 存在严重问题。它被设计成一种简单易读的格式。但如果解析它需要花费这么长时间，那么计划就失败了，因为解析不应该这么困难。
布拉德·艾普尔顿和罗素·阿勒比一直在开发的新一批 Pod 翻译模块已经开发多年。这不应该发生。我认为这不是布拉德和罗素的错；我认为 Pod 本身设计得不好，实际上比看起来要难得多。我多次尝试编写 Pod 和类似 Pod 的翻译器，这就是我发现的。
Pod 在某些方面非常好，但存在严重问题。目标是拥有一个既易于阅读又易于编写的文档系统，同时也易于程序处理和翻译。它在前两点上胜出；Pod 的阅读或编写比任何类似的东西都要容易。但对于算法处理，似乎有两种选择：你可以快速且草率地处理，忽略大多数细节，或者牺牲使用大量代码和极慢的运行速度来确保一切正确。
本：
perldoc需要进行彻底的改进。汤姆： 它应该被完全废除，由一个外观代替。
Mark Fisher的man替代品
马克·费舍尔宣布他已经为 Perl 编写了一个类似 man 的工具。不幸的是，它目前还没有可用。
兰达尔·施瓦茨建议，无论 perldoc 将变成什么样子，都应该用 perl -man 调用文档系统。他指出，许多企业 IT 人员正确安装了 perl 二进制文件，却省略了所有支持程序，如 perldoc。
Pod::Parser输出模型
托恩·霍斯珀尔询问 Pod::Parser 是否完成了它需要做的一切。目前，它只是将 pod 解析到低级层面，并返回一个标签列表。然后，翻译程序必须决定如何处理这些标签。托恩询问是否 perhaps Pod::Parser 应该更多地参与政策。例如，考虑这一点
=begin comment
foo
=head 1
=end comment
在 =begin comment 和 =end comment 指令之间的所有内容都被忽略。现在考虑这一点
=begin comment
foo
=cut
sub foo { ... }
=head 1
=end comment
注释部分是否一直持续到 =end comment 指令，还是它在 =cut 指令处停止？
托恩建议，Pod::Parser 可能会生成文档结构的更抽象数据树表示，并且翻译器将基于此进行操作，而不是从当前的低级表示（基本上是标记流）开始。这样，不同的翻译器就不会在这些类型的问题上做出不同的政策决策。
拉里说他已经思考了一段时间，应该有一个规范化的Pod到XML翻译器，并且说人们最终都会同意编写一个。
roffitall
最近对Pod::Man的修改破坏了roffitall程序，这是软件中几乎没人知道的另一个条目。roffitall位于源树中的pod/目录中，当你运行它时，它会将所有Pod文件转换为一份1400页的巨大后缀文件，其中包括世界上所有文档，包括标准模块的文档，以及它生成的目录。你知道这一点吗？我不知道。
这就是关于perldoc和相关问题的巨大多线程报告的结尾。
对perlre的补丁
汤姆·克里斯蒂安森向perlre提交了一个主要更新。
mktables.PL需要改进
unicode/lib/mktables.PL是生成Unicode代码编号到名称映射表的程序，这样你就可以说\N{BLACK SMILING FACE}并得到黑色笑脸字符；它还生成属性列表，这样你就可以说\p{IsUpper}来表示任何大写Unicode字符。拉里指出了该程序中存在的一些问题，这些问题需要在5.6.1之前解决。
没有人回复，所以如果你有兴趣帮忙，这是一个成为英雄的机会。
拉里：无论如何，这周有人有空闲时间吗？我没有，而且这个问题真的需要尽快解决。此外，这是Perl黑客技术，而不是C黑客技术，那应该是件有趣的事情。
Jarkko仍在尝试赠送Configure南瓜
你想成为重要人物吗？这是你的机会。
推入散列
布赖特·登纳建议
push %hash, key => value, key2 => value2;
应允许。
普遍的反应是消极的。人们提出了一些观点：已经有了一种简单的方法来做这件事
@hash{key1, key2} = (value1, value2)
它创造了一种未满足的预期，即pop、shift和unshift也将适用于哈希表。它创造了一种未满足的预期，即
%hash = (apple => 'red');
push %hash, apple => 'green';
将不会像数组情况那样覆盖'red'。无论你希望它有什么意义，都可以通过子程序轻松提供
sub hashpush(\%@) {
my $hash = shift;
while (@_) {
my $key = shift;
$hash->{$key} = shift;
}
}
这之前已经出现过，Yitzchak Scott-Thoennes提醒我们，当时的结论是
%hash = (%hash, key => value, ...);
应该优化。任何志愿者吗？
Damian的作业加载器
达米安·康威有一个模块，它应该提供一个简单的接口来处理赋值语义的重载，特别是通过防止将除特定类型的对象以外的任何对象赋给特定变量来提供有类型变量。例如
use Class::ifiedVars;
classify $var => 'ClassName';
现在，如果你尝试将一个不是ClassName对象或其子类的对象赋值给$var，你会得到一个运行时错误。
还有很多其他功能。达米安计划将其名称更改为更不异常的名字。
伊利亚询问这与达米安的PREPARE方法有什么不同。
my Dog $snoopy;
达米安回答说这与它正交。例如
my Dog $snoopy;
$snoopy = Alligator->new();
$snoopy->pat(); # Invokes Alligator::pat
$snoopy->{age}++; # Might update the wrong field
有人询问PREPARE在哪里有文档。伊利亚回答说，由于5.6.0中的一个错误，它尚未实现。
达米安和伊利亚就模块是否是一个好主意进行了长时间的交流。这导致彼得·斯科特询问何时实施审查。
各种
大量的错误报告、错误修复、非错误报告、问题、答案以及少量垃圾邮件和垃圾信息。
下周再会，我谦卑而顺从的仆人：
标签
反馈
这篇文章有什么问题吗？请通过在GitHub上打开一个问题或拉取请求来帮助我们
