Hi,
I am looking a bit into the usage of our old parser and keeping in mind
the new parser we want to eventually make the default.
But one problem I talked about in the past already is the direct usage
of antlr2 types in something else than the parser itself. Moving the
current parser into a subproject has the nice effect of highlighting
those problems, since anltr2 classes are then not automatically part of
the main module anymore.
And then you find things like this:
if (cause instanceof NoViableAltException) {
return isEofToken(((NoViableAltException) cause).token);
} else if (cause instanceof NoViableAltForCharException) {
char badChar = ((NoViableAltForCharException)
cause).foundChar;
return badChar == CharScanner.EOF_CHAR;
} else if (cause instanceof MismatchedCharException) {
char badChar = (char) ((MismatchedCharException)
cause).foundChar;
return badChar == CharScanner.EOF_CHAR;
} else if (cause instanceof MismatchedTokenException) {
return isEofToken(((MismatchedTokenException) cause).token);
}
The cause is from a SyntaxErrorMessage (actually cause is the cause of
the cause). Basically this tells me we are lacking the capability to
handle this case with only groovy-core classes. For the sake of
compatibility I don´t think we should get rid of the cause, but extend
SyntaxError(Message) or SyntaxException to support the transport of the
missing information.
I could now try to make a single class to cover all of the cases above,
which means a token (maybe expecting) and foundChar (maybe expectedChar)
and the problem, that if I have a token I do not have a char and vice
versa. I could work with Char...
if I want to project the given case and use the classic subclassing
approach I would produce two new subclasses of SyntaxException. If I
wanted to support the expected token or char, it would be 4 classes.
Any opinions on that?
bye Jochen
