Roll library tightly coupled with click

[Vlek]

Due to how parsley works, in order to have more information available to be printed using click, I had to couple things tighter than they really ought to be. This becomes an issue because I believe that the roll library cannot be imported and used by itself without weird output. It'll also have a messy namespace with click stuff inside of it.

[Vlek]

For posterity, I want to point out that I found a different way to have handled this than to change the underlying parser that would likely have been just as clean:

The problem I was running into is that a dice roll was returning the sum total of the rolls based on the input that was given. This meant that the individual roll data was being washed away and the process continued until there were no other operators to use against the different operands.

The way that I was choosing to solve this is to have everything tightly coupled and have click echo out when a dice roll had the verbose flag set. Another option was to have another object in maybe global scope keep track of all of the rolls made, but that also would not have been preferable as it would have been a code smell from creating potential side effects. Instead, I have realized that I could have used an option to hold both the roll results for all previous rolls as well as for the current total for all operations made since the first roll:

Example:
1d20 + 2

After the roll,
RollResult{ total: 7, rolls: [ [ 7 ] ] } + 2

Finally,
RollResult{ total: 9, rolls: [ [ 7 ] ] }

This RollResult object then keeps all future rolls inside as a nested list in rolls. That way, when we finally get to the point that we would like to present this information when the verbose flag is set in the click command, we can loop through and print them.

However, while this would have worked, all of the operations would have needed a veneer in order to deal with the fact that I am now throwing this object against them OR I would have needed to tell it how to handle the new object using operator overloading. The latter being preferable.

In the end, while this particular problem could have been fixed without changing the parser and redoing most of the underlying code for this project, I believe that it was still the right thing to do because, while I like how parsley works, it was no longer maintained as the last commit was in early 2013. Anything new could potentially break it.