IRC events come in very heterogeneous forms along the lines of:
:sender.address.tld TYPE [args...] :content
:sender!~ident@address.tld 123 [args...] :content
The number and syntax of arguments for types vary wildly. As such, one
common parsing routine can't be used; there are simply too many exceptions.
The beginning :sender.address.tld is *almost* always the same form, but only
almost. It's guaranteed to be followed by the type however, which come either in
alphanumeric name (e.g. PRIVMSG,
INVITE, MODE,
...), or in numeric form of 001 to 999 inclusive.
What we can do then is to parse this type, and interpret the arguments
following as befits it.
This translates to large switches, which can't be helped. There are simply
too many variations, which switches lend themselves well to. You could make
it into long if...else if chains, but it would just be the same thing in a
different form. Likewise a nested function is not essentially different from
a switch case.
Functions related to parsing IRC events.
IRC events come in very heterogeneous forms along the lines of:
:sender.address.tld TYPE [args...] :content
:sender!~ident@address.tld 123 [args...] :content
The number and syntax of arguments for types vary wildly. As such, one common parsing routine can't be used; there are simply too many exceptions. The beginning :sender.address.tld is *almost* always the same form, but only almost. It's guaranteed to be followed by the type however, which come either in alphanumeric name (e.g. PRIVMSG, INVITE, MODE, ...), or in numeric form of 001 to 999 inclusive.
What we can do then is to parse this type, and interpret the arguments following as befits it.
This translates to large switches, which can't be helped. There are simply too many variations, which switches lend themselves well to. You could make it into long if...else if chains, but it would just be the same thing in a different form. Likewise a nested function is not essentially different from a switch case.
See the /tests directory for more example parses.