Consider making ColorScheme immutable

[remkop]

Following up on #516.

With the new execute API the ColorScheme class will start to play a more central role.

I’m considering making the ColorScheme class immutable. This will be a breaking API change. Should it be deprecated first, or not changed at all, or is the upcoming 4.0 release a good time to make breaking changes?

Feedback very welcome!

(cc @bobtiernay-okta @bbottema )

[remkop]

(Thinking out loud, unsure if this could be made to work...)
One idea may be to introduce a superclass of ColorScheme, and make this superclass immutable. We would deprecate ColorScheme in 4.0, and make it final. In a future version we would remove ColorScheme and make its superclass final`.

Ideas for superclass names:

• ColorTheme
• ColorStyle
• ColorTemplate
• StyleTemplate
• StyleSheet
• TextStyle

[bobtiernay-okta]

or is the upcoming 4.0 release a good time to make breaking changes?

Yes, I think it's a great opportunity personally.

On a related note, have you looked at the JLine3 abstractions in this area for inspiration? I'm not sure they are inline with what you are thinking, but there does look like some good thoughts here.

https://github.com/jline/jline3/tree/master/terminal/src/main/java/org/jline/utils

In particular the Attributed* classes. I'm not suggesting this naming, just might be useful to look at the decomposition and why.