Skip to main content

Timeline for RPSLSMB OOP Version 2

Current License: CC BY-SA 3.0

6 events
when toggle format what by license comment
May 28, 2014 at 18:43 vote accept BenVlodgi
Mar 17, 2014 at 20:56 comment added ChrisW "Hard to verify" is high on my list of priorities to fix: because a main reason for doing a code review is "verification". I want to look at code (and data) and verify (by inspection) that it's correct. Alternatively I'll look to see whether code is self-verifying (e.g. your code could have a run-time check/assertion that most pairs are defined twice: once as a winner and again as a loser). Or (last resort) I'll look for an exhaustive list of unit test cases.
Mar 17, 2014 at 19:23 comment added BenVlodgi That is a valid point, and would replace what I have right now just fine. I may want to keep it this way in-case later I add other strange Gestures. You are correct, this current strucutre is difficult to verify
Mar 17, 2014 at 17:37 comment added ChrisW In that case I'd suggest adding a bool? or an enum { WinAndLose, BothWin, BothLose } to the list of tuples I suggested: to make that explicit: because it's difficult to verify/inspect the data you have. Also, on loading the list, verify that the same (unordered) pair of gestures isn't defined more than once in the list.
Mar 17, 2014 at 17:08 comment added BenVlodgi Your different Dictionary implementation would work, if Monkey and Banana weren't so weird. In standard RPSLS I would certainly go with that approach, but here Monkeys lose to each other, and Bananas win to each other instead of tie-ing. I see your point with the Player Abstraction, I'll think about that. And the reason WhatHappensToMe is called twice is because of the weird win-lose-tie cercumstances introduced by Monkey and Banana. GetReason looking up rules again I may indeed change if I implement a class structure for rules. Everything else I agree with :)
Mar 17, 2014 at 16:39 history answered ChrisW CC BY-SA 3.0