Mere moments ago, quoth I:
On 23/09/2020 12:52, Vinnie Falco wrote:
It is the opposite of SRP violation. basic_parser is concerned only with parsing and not keeping track of the full value. The responsibility of tracking full values is moved to the caller. That way, basic_parser does not impose its opinions on how the full value should be stored. This was litigated in earlier posts if I recall (Peter?).
Except it does, because it parses into int/uint/double, which is inherently a storage decision. You might have a valid argument if it left that step to the handler to determine as well. (i.e. only providing on_number_part and on_number, just the text without any attempt to parse into a numeric type.)
It's not just a storage *decision*; in order to implement this interface with the observed behaviour it also means that basic_parser must currently actually have *storage* for partial numbers updated across multiple fragments. This is inconsistent with how it treats keys and strings. Hence I reiterate: it would be more consistent to delete those methods and only have on_number_part + on_number that provide just the text. (Make it parser's responsibility to do the actual text-to-numeric-type parsing, ideally via a helper class that user code can call too. Since it's the layer that's dictating the storage format via json::value.)
The current form of basic_parser could still exist, if you like, but it should be made an implementation detail and the complete-value basic_parser actually exposed to consumers.
I still think that it would be better to instead provide an interface that precomposes the text fragments, but that is a separate argument from the prior one, that can be treated separately. Perhaps you could provide both -- basic_parser as-is (but with the number parsing/storage removed), and another layer on top (custom_parser, perhaps) that is nearly identical but omits the _part methods to only provide precomposed keys/values. This is the one that most consumers of a SAX-style interface would be expected to actually use.