Language syntax #26

[DarthKipsu]

This is a fix for #26

Language comment styles are passed on using LanguageSyntax, this will require only new comment regexes to be added when creating a new language plugin. I have not yet added the syntax files for any of the plugins as I'm worried it will break any current exercises if the syntax for the comments is suddenly changed. For backwards compatibility, should single line java comments always be accepted?

[jamo]

Initial thoughts after first glimpse; it seems like there is a one to one relation for syntax plugin and language.
Could we generalise this a bit more; to have both // and /* <something>*/ to both be separate plugins.
And maybe then we could just blindly just use every possible filter for a given file or with annotations or more manually link plugins to specific files.

(In, say a maven project, we could have .java, .xml, .html, .js and .css files...)

[DarthKipsu]

Now you're able to build a custom comment syntax that can include all the comments you wish to support for a plugin. It defaults to Java single line comments if no syntax is given.

One way to improve might be by creating an enum to store the different comment regexes for all languages, so that if two plugins use the same language, they would not have to come up with the regex again. Not sure if using enums like this is a good practice?

[jamo]

Awesome!
I really like the CommentSyntax and the builder for it!

What I'm not fully sure about though is whether we want or need to have each different language plugin to say "I'm Going to allow there kind of syntaxes" but rather just have a set of plugins, each defined for a set of file-extensions so that it would just ask "Hey, I have this .js file - who wants to parse it"

That being said, it might be too early for that... -- anyways the builder makes building and adding these much nicer task!

[DarthKipsu]

I'm not sure what's the best way to do that. Should the file extension be checked in prepareStubFile() and prepareSolutionFile() and only create a CommentSyntax (or maybe get from a mapping of some sort) after checking the extension every time?

[jamo]

For both, stubs and solutions we need to process the files.. We could have a map<Extension, List<SyntaxPlugin>> and we would apply each available plugin for given file in order.
One nice way would be to do use reflection to build the filetype: syntaxPlugin map - maybe even with out having annotations.

A nice way with annotations and reflection could be to have @SyntaxPlugin(list of supported extensions) annotations