Instead of an association list and a type contract, let's use a hash
table and a structure. This is: more explicit, encapsulates state
more effectively, generates much of the cruft (constructors,
destructors) for me.
A hash table is more efficient when considering large player bases.
In particular, we'll be generating unique player IDs to make it a bit
more difficult for a malicious agent to guess another player's ID and
make bad requests.
Custom errors for malformed/nonexistent player IDs as well as a player
not having a high enough balance for the money requested.
This will allow me to encode more information in the errors, for
callers to use. I'm generally of the opinion that callers should be
checking error conditions before calling these functions, but per
Murphy's law it would be nice to have more information in the error
message.
This package defines a player data structure, collections of players,
and different interactions you can have with them:
- Extracting attributes (destructors)
- Checking if they're bankrupt or can bet
- Modifying a collection to adjust the balance of any one
player (including errors in case that isn't possible)
Found that I sometimes did a misinput which lead to losing a critical
card - implemented a function which asks for confirmation (with a
print out of the cards that will be redealt) before doing the redeal.
We've now got one of the major stages of the game down.
I think it's worth investing in some testing functions now - we've
reached just the level of complexity.
Like REPL stands for Read -> Evaluate -> Print -> Loop, here we
implement a similar loop which reads a set of indices for cards to
remove from the user, redeals those cards then loops back.
This keeps happening until either:
- the user does not want to redeal (empty input)
- there aren't enough cards for a redeal
