allow updates to existing cards

[sherrardb]

i left this stalled a while ago, but i figured i'd dust it off for inclusion in the next release. discussed preciously in #100 .

[sherrardb]

i have updated this branch based on issues outlined in #100

[andrewsolomon]

I think it would be helpful to add comments explaining the logic of post_card for the next maintainer. The reason I say this is because I look at all the if conditionals and I think:

• What happens if $card is not a ref, but not a token either (also - it would be good to explain what the /^tok_... means
• What happens if $card is a Token but doesn't have an id
• What happens if it's a ref, but not a Net::Stripe::Token and not a HASH? I suspect you're going to say "then it falls through to line 593" but it would be nice to make it clear that all possibilities are covered.

[sherrardb]

I think it would be helpful to add comments explaining the logic of post_card for the next maintainer. The reason I say this is because I look at all the if conditionals and I think:

• What happens if $card is not a ref, but not a token either (also - it would be good to explain what the /^tok_... means
• What happens if $card is a Token but doesn't have an id
• What happens if it's a ref, but not a Net::Stripe::Token and not a HASH? I suspect you're going to say "then it falls through to line 593" but it would be nice to make it clear that all possibilities are covered.

welllll... several times i was tempted to massage the structure of that sub to clarify and tighten, and i have been trying to resist the urge. but since you asked, i'll have at it :-)

[sherrardb]

@andrewsolomon i would appreciate your thoughts on

• the structure of the chained conditionals
• the lack of a terminal else/die, even though technically it shouldn't be necessary
• the structure and wording of the error messages, which are mostly mock-ups for reference
  TIA

[andrewsolomon]

@andrewsolomon i would appreciate your thoughts on

• the structure of the chained conditionals
• the lack of a terminal else/die, even though technically it shouldn't be necessary
• the structure and wording of the error messages, which are mostly mock-ups for reference
  TIA

I agree that there's lots of scope for making the code more robust. As long as you're confident that your testing covers any changes you make you should feel free to make the code better :-)

[sherrardb]

upon review (of my own code :-)) i see that i managed to both remove the code path that handles Net::Stripe::Card objects (remove appropriately, per #100) and re-add it later. my only guess as to why is that i also added a test case for Net::Stripe::Card objects, and therefore ended up trying to "fix" a brokenness that should not have been fixed.