Github user cestella commented on a diff in the pull request:
    --- Diff: 
    @@ -34,15 +34,15 @@
        * @param rawMessage
        * @return If null is returned, this is treated as an empty list.
    -  List<T> parse(byte[] rawMessage);
    +  List<T> parse(byte[] rawMessage, SensorParserConfig sensorParserConfig);
    --- End diff --
    @nickwallen I frankly dispute the notion that the MessageParser interface 
isn't clear or concise.  I think you are overstating the current state of 
    As for its conciseness, this is an interface with 4 methods, 3 of which 
have no default implementations.  I do not see an argument for it being bloated.
    Regarding its clarity, I think the only argument here is against 
`parseOptionally`, which I defended above, but I'll add this point of opinion 
and history.  It was added to not just provide backwards compatibility, but 
also to provide a more comfortable interface for those who aren't as 
comfortable with Java 8's Optional.  I do not see this as unclear, but I may be 
    On the whole, it feels like this discussion has shifted from a useful 
appraisal of the functionality added by this PR and into sometimes a discussion 
of rearchitecture of the parsing infrastructure and sometimes a 
[bikeshedding]( distraction.  I 
think we can do this without breaking compatibility with existing parsers and 
without damaging the clarity of the interface, which was the original complaint.
    As for a broader discussion of a rearchitecture of how we parse, I'd 
redirect interested parties to either the dev list where this is more 

If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at or file a JIRA ticket
with INFRA.

Reply via email to