Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rename a lot of core classes to match the correct naming scheme of the library #1961

Merged
merged 4 commits into from
Apr 16, 2020

Conversation

remi-stripe
Copy link
Contributor

@remi-stripe remi-stripe commented Mar 21, 2020

Took the opportunity to rename a lot of older classes that were never prefixed, paving the way for the release of the codegen-ed library in the next few months.

List of changes:

  • Renamed the class Fee to BalanceTransactionFee on BalanceTransaction
  • Renamed the class Outcome to ChargeOutcome on Charge
  • Renamed the classes Evidence to DisputeEvidence and EvidenceDetails to DisputeEvidenceDetails on Dispute
  • Renamed the class OutcomeRule to Rule and moved it to the Radar namespace
  • Renamed the classes ShippingMethod to OrderShippingMethod, StatusTransitions to OrderStatusTransitions and DeliveryEstimate to OrderShippingMethodDeliveryEstimate on Order
  • Renamed the class Inventory to SkuInventory on Sku
  • Fixed the type of NextPendingInvoiceItemInvoice on Subscription to be a DateTime?
  • FraudDetails on Charge is now a class ChargeFraudDetails instead of a dictionary
  • Removed Connect on the WebhookEndpoint resource as it is not supported

cc @stripe/api-libraries

@remi-stripe remi-stripe changed the base branch from master to integration-v36 March 21, 2020 20:58
@@ -2,7 +2,7 @@ namespace Stripe
{
using Newtonsoft.Json;

public class OutcomeRule : StripeEntity<OutcomeRule>, IHasId
public class ChargeOutcomeRule : StripeEntity<ChargeOutcomeRule>, IHasId
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So. I wanted to flag that one explicitly @ob-stripe.
It's quite an old property but, if I am not mistake, this should be a real API resource with an object field since this is expandable on Charge.outcome.rule. Really curious what your thoughts are here?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Strictly speaking we don't need the object field if the expandable field is not polymorphic. But AFAIK this is the only case of an expandable field where the expanded object is not an API resource with an object field.

I don't think it's worth fixing, but we should discuss this internally to decide if this is something we'd want to allow on other API resources in the future.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reason I'm asking is that, if we added object later the class would have the object value as a name. When right now it's kinda ChargeOutcomeRule and in a way it's annoying

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you think we should call this one Rule in the Radar namespace in that case so that in the future, if we add object it will likely be object: "radar.rule"?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should do the same thing as stripe-java to facilitate future codegen, so yes, ChargeOutcomeRule should be renamed to Rule in the Radar namespace: https://github.com/stripe/stripe-java/blob/master/src/main/java/com/stripe/model/radar/Rule.java. (Thanks for checking!)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed, PTAL

@remi-stripe remi-stripe force-pushed the remove-deprecated-and-renames branch 2 times, most recently from 98608dc to 225b3b8 Compare March 27, 2020 01:02
@remi-stripe remi-stripe changed the title [WIP] Remove deprecated and renames Remove deprecated and renames Mar 27, 2020
@remi-stripe remi-stripe changed the title Remove deprecated and renames Rename a lot of core classes to match the correct naming scheme of the library Mar 27, 2020
@ob-stripe
Copy link
Contributor

@remi-stripe Should we close this for now?

@remi-stripe remi-stripe changed the title Rename a lot of core classes to match the correct naming scheme of the library [WIP][dotnotmerge]Rename a lot of core classes to match the correct naming scheme of the library Mar 31, 2020
@ob-stripe
Copy link
Contributor

I've reset the integration-v36 branch, so you'll need to rebase to remove the extra commits.

@remi-stripe remi-stripe force-pushed the remove-deprecated-and-renames branch from 225b3b8 to a4fc708 Compare April 1, 2020 04:34
@remi-stripe remi-stripe changed the title [WIP][dotnotmerge]Rename a lot of core classes to match the correct naming scheme of the library Rename a lot of core classes to match the correct naming scheme of the library Apr 1, 2020
@remi-stripe
Copy link
Contributor Author

@ob-stripe Re-assigning to you for review again. Flagging I fixed another issue raised by @clement911 in #1969 (comment)

@remi-stripe remi-stripe assigned ob-stripe and unassigned ob-stripe Apr 1, 2020
@ob-stripe ob-stripe removed their assignment Apr 3, 2020
@stripe-ci stripe-ci assigned remi-stripe and unassigned ob-stripe Apr 15, 2020
@remi-stripe remi-stripe merged commit 4ff93af into integration-v36 Apr 16, 2020
@remi-stripe remi-stripe deleted the remove-deprecated-and-renames branch April 16, 2020 00:42
@remi-stripe remi-stripe mentioned this pull request Apr 16, 2020
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants