git-hulk commented on PR #1032:
URL:
https://github.com/apache/incubator-kvrocks/pull/1032#issuecomment-1290340725
@PragmaTwice Thanks for your explanation.
> We cannot always move next: for example, to parse (EX v1) | (PX v2) | v3,
we need first peek the token (EX or PX), then we can move next, otherwise we
may lose v3. For a parser, moving next at every step will severely damage its
parsing ability.
Yes, I got your point. What if we use the parser to iterator all tokens
instead of only flags. I will take `ZADD` command as example:
```C++
while(token = parser.next()) {
case "NX":
_flags = nx;
case "INCR":
_flags = incr;
default:
break;
}
while(parse.has_next()) {
status = parser.expected<double>()
parse.next()
status = parser.expected<string>()
}
```
> We need a method to forward error: this is where the sample code is
idealized, error handling needs to be abstracted
Yes, it's just a rough idea which didn't think carefully.
> We need a method to prevent different flags in the same layer: for
example, to parse [EX a | PX b] | [X | Y], we need to reject something like EX
v PX v, X Y or EX v X PX v, and accept EX v EX v, EX v X or Y PX v.
In my option, the parser should only care about how to iterator and the
type(or range) is right. For whether those flags are exclusive or not, it'd
better to handle outside the parser, or the parser will become more and more
complex.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
