动画做视频在线观看网站,淄博网站制作建设,邢台移动网站建设费用,站酷设计网站官看来可能是一种新的方法#xff0c;将可在java.util.streams.Collectors类JDK 12即会#xff0c;根据新方法的提出了基于Javadoc的文档#xff0c;“返回一个收藏家是将输入的元素两个规定的收藏家并将其结果与指定的合并功能合并。” 目前 #xff0c;此新Collectors方法的… 看来可能是一种新的方法将可在java.util.streams.Collectors类JDK 12即会根据新方法的提出了基于Javadoc的文档“返回一个收藏家是将输入的元素两个规定的收藏家并将其结果与指定的合并功能合并。” 目前 此新Collectors方法的建议名称为pairing 但该新方法的名称已成为重要讨论的来源。 此方法的名称引起了OpenJDK core-libs-dev邮件列表的广泛讨论。 尽管起初想将其标记为自行车脱落的示例或帕金森氏平凡定律 很容易但是我的经验是正确的命名比最初看起来更重要。 我已经看到很多情况下特定实现的逻辑都没有错但是随之而来的问题是由于沟通不畅或与命名较差的代码构造相关的错误假设而导致的与该实现的使用有关。 对于JDK中的主要API毕竟如此认真地考虑此方法参数的名称并不奇怪。 讨论始于Peter Levart的帖子“ BiCollector ”6月17日他在开始时提出了一个问题“您是否曾经想使用两个Collector将同一Stream收集到两个不同的目标中” Levart提供了一个实现此类“ BiCollector ”的示例并询问这是否是可以添加到JDK中的东西类型。 毫不奇怪事实证明这是其他人所期望的并且提到了一些替代的现有实现 Kirk Pepperdine和Tagir Valeev的streamex 实现 。 在讨论了“ BiCollector”的多种实现方式之后 Tagir Valeev创建了一个OpenJDK“ 我自己的实现方式的初步Webrev ” 并将其发布以进行审核 6月15日。 在那篇文章中 Valeev特别指出他为该方法编了“ pairing”配对的名称并补充说“由于我不是英语母语人士所以我无法判断它是否是最佳选择因此欢迎更好的主意。” 那就是“ 打开了水闸 ” 尽管围绕拟议的“ BiCollector”的其他实现细节进行了一些有趣且有意义的讨论现在在拟议的代码中为“ Collectors.pairing…”但该方法的命名贡献最大。在6月21日的帖子中 Valeev总结了提议的名称并附有关于每个建议的评论我在此处复制了该列表但没有深刻的评论 平分 开球或开球 双工 分叉 或分叉 复制者 复制 扇出或扇出 分布 窃听 分裂 解压缩 biMapping 二者皆是 collectionToBothAndThen 收集双方 collectionTo 双向收集 扩大 分叉 对于那些对上述提议的名称“赞成”和“反对”的论点感兴趣的人我建议查看Valeev的原始帖子 。 上面链接的大多数带有名称建议的帖子都为其首选名称提供了论据并且对OpenJDK贡献者认为方法名称中的哪些方面可能有助于或阻碍对该方法的理解有一些有趣的见解。 在为该方法命名后讨论就此添加到Collectors API上了一段时间直到Valeev今天发布了“ ping消息 ”并链接到最新的webrev以供审核将since 11更改为since 12 。 响应此“ ping”消息 收到有关所建议方法的最后一个参数名称 当前称为“ finisher ”的反馈 这再次提醒了命名对于我们许多人的重要性。 在core-libs-dev邮件列表上有关此主题的其他文章提醒我们要将这种新方法添加到Collectors 公共API中 仍然需要做一些事情包括发起人自愿检查和赞助更改集 。以及对CSR 兼容性和规范审查 的需求和“ 几个完全了解Streams设计的审查者 ”。 Brian Goetz在此线程上的帖子总结了为什么命名此提议的方法如此困难 在这里命名的基本挑战是该收集器要做两件事或可能三件事将流复制为两个相同的流“ tee”将每个元素发送给两个收集器“ collecting”然后合并结果“精加工”。 因此所有的单字名称配对发球解压缩biMapping仅强调操作的一半而准确地捕获整个工作流程的名称teeingAndCollectingAndThen则很笨拙。 戈茨Goetz 的同一篇文章也反对该方法名称的“合并”或其派生词因为“沿合并的名称可能会错误地给出合并是按元素进行的想法而不是复制流进行收集和合并”结果。” 我发现一些建议的方法名称是合理的但是我相信希望有一些是出于幽默的尝试。 JDK-8205461 [“合并其他两个收集器的结果的创建收集器”]是描述此问题的“增强”“错误”。 目前它的描述开始于“将新的Collector添加到Collectors类中以合并其他两个Collector的结果”然后明确指出“应添加一个API方法名称尚待讨论”。 如果您曾经想在公共JDK API中命名方法那么这可能是您的机会 我已使用此博客文章来尝试完成两件事 从JDK 12开始使人们意识到这种方法很可能在公共API中可用 举例说明命名为何如此重要以及为什么命名可能与技术实施一样困难 对于任何人来说正确的命名都可能会很困难即使我们中的母语是英语的人也是如此 尽管实现中的一个或多个名称可能会更改但是从逻辑上讲 当前提出的实现很可能与最终将与JDK-8205461结合交付的实现非常接近。 翻译自: https://www.javacodegeeks.com/2018/08/jdk-12-merging-collectors.html
