Hi Robert,
robert burrell donkin schrieb:
>> This could be done by achieving a nearly 1:1 relation between the
>> entities from the ABNF and ANTLR rules.
>> This allows a straight forward development and makes review for
>> correctness quite effective.
> +1
>
> anything i can do to help?
You could start a grammar for the Search command. At best along with
unit tests.
Not too much validation for the beginning but just the information "the
parser can parse this string without errors".
IMO and AFAIK Antlr is well suited for unit testing. It produces one
java method for each sub-rule, so it can be tested separately.
tree.toStringTree() could be useful and sufficient to make first assertions.
One note to object tree construction, because it was hard for me to find
out:
You can mark tokens to be a tree-node with a ^ and ignore tokens with !.
While working with the fetch command I noticed that it is not very
tree-friendly because different kinds of information just come in a row.
(Maybe another design deficiency?)
The object-tree should be well structured and easy to evaluate without
"searching" for information.
That's why I made much use of virtual tree nodes:
1. define it in the tokens { RULE; } section
2. add a {#rule= #([RULE, "RULE"], #rule);} line to the rule
definition to make it a node.
What still needs to be done and could be shared by Search, fetch and
other commands, is to adopt the definition for atoms/strings/quoted
strings from the ABNF. (Maybe we need a more relaxed definition because
clients don't follow RFC exactly.)
For the first tests WORD: ('a'..'z' | 'A'..'Z' | '.')+ ; seems to be
sufficient.
Another issue is case insensitive parsing. I'm sure there is a solution
for ANTLR.
Joachim
P.S.: Lost in moderation? I replied already on sunday by a different address,
sorry for sending twice
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
