Why is javaslang CharSeq final?

Question

We're all familiar with the argument about why String is final in java.

However, I was wondering why javaslang's CharSeq is final too.

Given javaslang's FP inspirations and the fact that Haskell allows type synonyms, I would have thought this would be a good opportunity to make CharSeq non-final with maybe the methods as final.

A non-final CharSeq would then allow me to extend it with an empty body to create a good approximation of type synonyms. This would avoid the boilerplate of the tiny type pattern for cases where the additional type safety is desired.

I'm sure there is a good reason why this is not the design, which is why I am asking here.

UPDATED 16-Dec-2016: I've raised an enhancement request with the javaslang team on github as issue #1764.

Answer 1

All the same reasons for and against apply.

Java's designers believed that guaranteeing immutability was worth losing the ability to subclass.

Slang's designers agree, and took the same approach with their "String", CharSeq.

The only internally consistent way to disagree with this design, would be to also disagree with String's design, which has stood the test of time.

Sometimes we wish we could subclass String, and we can't - but it doesn't sting us often. If you really want to, you could write your own String that proxies all methods to a java.lang.String delegate. You could subclass that as much as you like. It would be your own responsibility not to introduce mutability.