0

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.

Community
  • 1
  • 1
James Burton
  • 132
  • 9

1 Answers1

2

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.

slim
  • 40,215
  • 13
  • 94
  • 127
  • Thanks, but are you sure all the same reasons apply? Since `CharSeq` is not a `String`, surely the JVM/classloading/security/performance reasons don't apply? – James Burton Dec 16 '16 at 16:29
  • There's nothing magic about a `String` -- it's just a Java class with a private `char[]` field that it manipulates. Why wouldn't the same JVM/classloading/security/performance reasons apply to any other class? – slim Dec 16 '16 at 16:42
  • So do the same arguments therefore apply to any class? i.e. is the pro `String` final argument simply saying `extends` is always 'bad' for performance etc?If so, then is the reason that javaslang `CharSeq` is final due to JVM/classloading/security/performance reasons and not due to an FP design consideration? – James Burton Dec 16 '16 at 17:14
  • Hmm, so (after thinking for a bit helped by your answer) I think I need to know if javaslang designers value guaranteed immutability over Haskell-ish type synonyms. If they do, then I'd love to know exactly why (since a determined user can always work around the immutability as you point out). – James Burton Dec 16 '16 at 18:17
  • OK, I'm going to accept this as the answer. Daniel Dietrich has added a lengthy comment on [#1764](https://github.com/javaslang/javaslang/issues/1764) which does indeed echo the same concerns as a java `String`. I'm not completely satisfied - I don't think I have a good explanation why a final equals method does not address the concerns. – James Burton Dec 19 '16 at 10:00