Lets not be too shy about just using `extend` instead of `include` here
when it's more appropriate to do so. The advantage to this approach is
that the module can be either extended _or_ included with this change,
but couldn't be without it due to the `ClassMethods` meta-magic.
List has already started doing this as of #314, so we don't have to be
afraid of breaking convention here.
Usage on a top-level collection:
```
Stripe::Customer.list.auto_paging_each do |customer|
puts customer
end
```
Usage on a subcollection:
``` ruby
customer.invoices.auto_paging_each do |invoice|
puts invoice
end
```
We've also renamed `#all` to `#list` to prevent confusion ("all" implies
that all resources are being returned, and in Stripe's paginated API
this was not the case). An alias has been provided for backward API
compatibility.
Fixes#167.
Replaces #211 and #248.
As detailed in issue #119, we've somewhat unfortunately been allowing
object attributes to be passed in during a #save because we mix any
arguments directly into the serialized hash (it seems that this was
originally intended to be used more for meta parameters that go to the
request).
As also noted in #119, this use causes problems when certain types of
parameters (like subobjects) are used. We're now left in the somewhat
awkward position of either:
1. Removing this functionality on #save and breaking what may be
behavior that people depend on.
2. Fully support this mass assignment.
This patch takes the second path by extracting a new #update_attributes
method and using it from #save. It's still far from a perfect approach
because keys that have the same name as certain options (e.g. `req_url`)
are not going to work, but it should capture the behavior that most
people want.
Fixes#119.
This patch adds question marks helpers (e.g. #paid?) for any values in a
StripeObject that are a boolean. This is fairly idiomatic Ruby in that
it behaves similarly to other libraries like ActiveRecord.
Note that a caveat here is that nullable booleans will not get a helper
added for them if their current value is null. For this reason, we
should eventually prefer to derive these methods from some sort of
programmatic API manifest.
Replaces #257 and #274.
This makes ListObject behave a little more like an Array in that it gets
an #empty? helper. This should fit pretty well with the Enumerable
methods that it already has.
Replaces #193.
This pulls the `Enumerable` mixin into `ListObject`. There is some
question in pulls like #167 as to the future of `ListObject` and how it
might change when pagination is introduced, but because we're unlikely
to make any backward incompatible changes to the API, it's likely that
`ListObject` will continue to represent a page of data that's been
extracted from the API. Given that assumption, pulling `Enumerable` in
should be relatively safe.
Fixes#227.
When constructing an object using .construct_from treat keys that are
strings the same as keys which are symbols by calling Util's
symbolize_names on an input hash. This makes guarantees around
consistency a little better.
Fixes#151.
Modifies the behavior of an update so that it can create an object if it
was new. This allows an "upsert"-like functionality where the SDK will
tend to do the right/expected thing.
This is a tad janky in that it checks for the existence of a class-level
`.create` method which is expected to come from a different module, but
most modules in the project are already fairly deeply intertwined and
co-dependent.
Fixes#165.
