Make SyntaxConstants enum?

[pskowronek]

Describe the solution you'd like SyntaxConstants is now iface that contains constants of supported syntax styles. Would be far better to make it an enum, because:

• it can be easily iterated
• RSyntaxTextArea.setSyntaxEditingStyle if accepting enum to be less error prone
• the enum could also return human accepted name of style ("D", "C++", "JSON" etc).

Are there any workarounds? Nope, only reflection to iterate over this iface.

Additional context Would be useful to automagically generate the list of accepted syntax styles.

[bobbylight]

I've thought about this, but doing so would remove the ability to add your own languages. Is there a way to use an enum and preserve that functionality?

[Sailsman63]

I've been thinking on this a bit and it is doable, but it would require some refactoring/restructuring that would be a breaking change. (I've spent a bit of time looking at some other problems that have similar-shaped solutions.)

It would look something like this:

interface SyntaxConfiguration
{
    Class<? extends TokenMaker> tokenMaker()
    Class<? extends FoldParser> foldParser()
    // Include anything else that currently uses SyntaxConstants as a key into a
    // list of configuration options
}

public enum CoreLanguageConfiguration implements SyntaxConfiguration
{
    JAVA_CONFIG
    {
        Class tokenMaker() { return JavaTokenMaker.getClass(); }
        Class foldParser()  { return CurlyFoldParser.getClass(); }
    }
}

And then, when setting a language for a document (Currently in RSyntaxDocument) you would call: setSyntaxConfiguration(CoreLanguageConfiguration.JAVA_CONFIGURATION); where the method takes an argument of type <? extends Enum<T> & SyntaxConfiguration>. Third party code adding another language just needs to provide an enum with their supported languages.

This removes things like AbstractTokenMakerFactory, in favor of the configuration constant carrying that data all in one bundle.