Safer attribute assignment

[brandur]

When someone assigns to a StripeObject's attributes with an accessor:

account.email = ...

Or with a mass assignment:

account.update_attributes(
  email: ...
)

We should make an effort to determine that the property assigned is actually one that exists on the resource. This will prevent such problems as a buggy programs assigning to misspelled properties, and then only realizing the mistake much later.

This will probably be done via some kind of machine-readable API manifest as with the testing stubs in #243. Marking as "future".

[kyleconroy]

Agreed with the future tag here, as this is something that we cannot do today. I hesitate to add this feature as it ties stripe-ruby directly to a specific API version. This is probably a larger conversation that we need to have.

[brandur]

Agreed with the future tag here, as this is something that we cannot do today. I hesitate to add this feature as it ties stripe-ruby directly to a specific API version. This is probably a larger conversation that we need to have.

+1.

One other thing to consider along the same lines is that if we start programmatically generating methods that map to API calls, we will also run into the same issue. You could have a Ruby method for a call that isn't actually available on your account if your gem is newer than your anchored API version, or vice versa.

One possible approach that would solve both problems is to ship SDKs with a built-in version override so that they always talk to the API version that they're related to.

Definitely part of a larger conversation though!

[brandur]

Aside: it's interesting to note as well that the unofficial .NET Stripe SDK already took the approach of pegging an API version.