Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Resurrecting a previous proposal — #164
This is basically a step 1 that allows multiple parsers to co-exist without breaking the default behaviour. A new parser is registered under a specified name and then can either be used explicitly by providing
:parser
option to theMonetize.parse
or implicitly by setting theMonetize.default_parser
.The change here should be pretty straightforward, the bulk of it is moving the current parser to
optimistic_parser.rb
, reserving theparser.rb
for the interface definition.I've kept the diff as tight as possible, however I feel that a worthy addition would be to change the semantics of a parser class slightly. Right now it represents a parsing of a single input, meaning that a unique class gets created every time
.parse
is called. There aren't lots of benefits to this design besides easy access to the input and options supplied to theMonetize.parse
(which creates some confusion in the current parser asinput
is mostly shadowed anyways). An alternative would be to treat the parser class as a pre-configured parser ready to parse a given input.In the next PR I'll bring the
StrictParser
in, which will allow us to release it and gather feedback.As a side note — given that
monetize
is mostly a parser with a few smaller additions I wonder if the strict parser should be a separate gem altogether assuming most people would want to use one parser across their codebases. This also allows for a super speedy strict parser gem written in Rust or C (which you don't want to impose on people already usingmonetize
, because it adds installation time dependencies). We can discuss this later, just something to keep in mind.