
每当我们提高Java中类型推论的范围时,我们都会得到“但是您也可以推论这一点,为什么不呢?”。(或者有时候,礼貌些。)
有关设计类型推断方案的一些一般性意见:
- 推理方案将始终具有局限性。总是有些情况下,我们无法推断出答案,或者最终推断出令人惊讶的事情。我们越难推断所有事情,就越有可能推断出令人惊讶的事情。这并不总是最好的权衡。
- 选择“但是肯定可以在这种情况下推断”的例子很容易。但是,如果这种情况与没有明显答案的其他情况非常相似,我们就解决了这个问题-“为什么X和Y都是Z,它为什么适用于X但不适用于Y?”
- 总是可以采用推理方案来处理增量情况,但是几乎总是存在附带损害,其形式是在其他情况下获得更差的结果,不稳定的增加(在这种情况下似乎无关的更改可能会改变推断的类型),或者更加复杂。您不想仅针对可以推断的案例数进行优化;您还希望针对受过教育的用户进行预测,以预测哪些将起作用,哪些将不起作用。在这里画一条简单的线(例如,不要费力去推断数组初始化器的类型)通常是一个胜利。
- 考虑到总是存在限制,选择一个较小但定义更好的目标通常会更好,因为这可以简化用户模型。(请参阅有关“为什么不能对私有方法的返回类型使用类型推断的相关问题。答案是我们可以做到这一点,但是结果将是更复杂的用户模型,以实现较小的表达利益。我们称之为“”复杂性回报率不高。”)
欢迎分享,转载请注明来源:内存溢出
微信扫一扫
支付宝扫一扫
评论列表(0条)