-
Notifications
You must be signed in to change notification settings - Fork 93
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
Add charge parameter to subscription termination functions #374
Merged
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wondering if there's other ways we could pass in this parameter... having unnamed Boolean parameters doesn't make for very readable code. Having to pass in an array with the options is more verbose but we'd be able to have a understandable bit of code:
vs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did some research, and named parameters have apparently been a subject of debate in the PHP world. Since they don't exist at the moment, we basically have two options:
Do your suggestion of passing in an
options
array. This has the benefit of making it more explicit, but you lose the ability to specify the type of the option, so you have to do some validation within the function. At that point, would we throw an exception ifcharge_for_unbilled_usage
was not a boolean? Would we even check for the type, or would we just check for its presence and if it's not falsey, assume that it's meant to be true? It's hard because the default by the API is true and not false, so I'm not a huge fan of this solution even though it's better than what I have now.We could create class constants that evaluate to
true
orfalse
so that people can pass in something that makes it more clear. So the API would look likeand
I'm open to suggestions on the naming of these class constants should we go this route.
The nice thing about option number 2 is that it leaves it up to the programmer as to whether they want to use our class constants or not, but the validation of what's being passed in is still super simple.
Oh, and there's always the secret option number 3, which is just forget about the 3 existing
terminateAnd...
methods, and make theterminate()
method public, allowing people to pass in what they like as therefundType
andcharge
variables. But this feels like moving backwards.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Your point about secret option 3 actually hints at another option, we could just make that part of the function signatures:
terminateAndPartialRefundIgnoreUnbilledUsage
... that could get too crazy but is an option.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, the benefit of doing that would be that we wouldn't break anything for anyone, no one would have mysterious unreadable booleans being passed into the method, and people have to explicitly choose to go against the default...
I don't think including those would be any crazier than option number 2, but I like that it keeps with the pattern we already had.
Shall I go ahead and change over to that pattern?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd prefer keeping it simple and leaving it as a simple boolean parameter. The documentation should suffice for the small percentage of people who do not want to use the default of
true
. If we believe we may expand beyond this one parameter then we might want to consider another option.