为什么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的设计师认为保证不变性值得失去子类化的能力。

俚语设计师同意，并采用与＃34; String＆＃34;，CharSeq相同的方法。

唯一不同意这种设计的内部一致方式，也是不同意String的设计，这经得起时间的考验。

有时我们希望我们可以继承String，但我们不能 - 但它并不经常刺痛我们。如果你真的想，你可以编写自己的String代理所有方法到java.lang.String代表。您可以根据需要对其进行子类化。不引入可变性是你自己的责任。