java - 为什么 javaslang CharSeq 是最终的？

Question

我们都熟悉 argument关于为什么String在 java 中是最终的。

但是，我想知道为什么 javaslang 的 CharSeq也是最终的。

鉴于 javaslang 的 FP 灵感以及 Haskell 允许的事实 type synonyms ，我本以为这将是一个很好的机会来制作 CharSeq非最终的，可能方法是最终的。

非最终版 CharSeq然后，我可以用空的主体来扩展它，以创建类型同义词的良好近似值。这将避免 tiny type 的样板。需要额外类型安全的情况的模式。

我确信这不是设计的原因，这就是我在这里问的原因。

更新于 2016 年 12 月 16 日:我已向 github 上的 javaslang 团队提出了增强请求，问题为问题 #1764 。

Answer 1

所有支持和反对的理由都相同。

Java 的设计者认为，保证不变性值得失去子类化的能力。

Slang 的设计者对此表示同意，并对他们的“String”、CharSeq 采用了相同的方法。

不同意此设计的唯一内部一致的方式就是不同意 String 的设计，该设计经受了时间的考验。

有时我们希望能够继承 String 的子类，但我们不能——但这并不经常让我们感到困扰。如果您确实愿意，可以编写自己的 String 来将所有方法代理到 java.lang.String 委托(delegate)。您可以根据需要对其进行子类化。您自己有责任不引入可变性。