This would unblock #2010.
Closes#2032.
Closes#1880.
I know this comes out of the blue, but it seems to me the right change to do. This is a proposal, let me know what you think.
First, I started with the fact that we need to make `CancelWhen()` public.
Then, I realized that I don't like the `CancelWhen()` naming. `CancelAt()` is better?
But `CancelAt()` sounds like an order to do something, not as getter.
So, it should be named `Get...`. `GetCancelWhen()`? `GetCancelAt()`? Sounds strage.
`GetDeadline()` - not bad, bit it is not that clear, what the deadline is.
And I looked at the `WithDeadline()` method. And in comment, the first line is `@brief Create a context with expiration.`.
"Expiration" sounds better explanation for the essense of the "deadline".
So, I went with `GetExpiration()`. I think "Expiration" is also a better name, because should we want to add the method called "bool IsExpired()", it comes naturally using the existing terminology, sounds better than "`IsPastDeadline()`".
Next thing - if we have "`GetExpiration()`", it is strange to have a method called `Get()`. So, we have `WithExpiration()` and `WithValue()`. So, it sounds like the getter should be called `GetValue()`. I did that rename as well.
Then, I looked at "`With...`" method naming. It is a factory method. If for getters we have `Get`, then for factory methods we should have `Create`. So, I renamed `WithExpiration()` and `WithValue()` to `CreateWithExpiration()` and `CreateWithValue()`.
Then I looked at `Context::time_point` typedef. First, in general, if we can avoid public typedefs, it is better, because we don't need to document them and worry if we broke client code when we change them.
Second, it is strange that we use `Azure::DateTime` everywhere, but not in context.
So, I replaced it with `Azure::DateTime`. It is good because it allows us to drop to/from epoch conversions (#1880), and really all that extra dance we do to cast to representation and back to datetime is the ways to stay within legal type casting limits of compiler type declaration, while in reality there isn't much that is happening in the code: `DateTime` is essentially an `int64`, and with all these conversions to epoch time, then to representation and back, compiler does not generate real code, it still operates with that only `int64`.
Why we cast to `DateTime::rep` and back at all? Context stores it as `atomic`, and I am not questioning that. You can't get `std::atomic<DateTime>` today explicitly, so we "extract" representation (`int64`) and store it as `std::atomic<DateTime::rep>`, which is the same thing as `std::atomic_int64`.
-- Update: --
1. "Expiration" => "Deadline" (Jeffrey's request)
2. Added `Context::HasExpiration()` (response to Jinming) // plus, we do have `HasValue()` so why not have `HasDeadline()`.
3. `WithDeadline()`, `WithValue` => Two overloads of `CreateChildContext()` (my own initiative).
-- Update 2: --
`CreateChildContext()` => `WithDeadline()`, `WithValue`
-- Update 3: --
Removed `HasDeadline()`
* Simplify the design of Response<T> for usability.
* Revert changes to operation<T> to keep the changes single purpose.
* Update many of the response<T> call sites based on API changes.
* Update all remaining callsites and fix clang formatting.
* Update Response<T> documentation.
* Fix clang formatting.
* Remove status code from the Response<T> public surface area.
* Update the changelog.
* Fix up CL wording and remove commented-out change to operation<T>.
* Fixed test by actually calling a method.
* Fix up key vault test by not taking ownership of raw response.
* Fix call to get status code in test.
* Add new line at end of keyvualt live test file.
* Make a local copy within keyvault pipeline to avoid compilers re-ordering things.
* Make the fixes to the recent keyvault changes.
* Fix key vault pipeline to address ImportKey test failure
* Increment package version after release of azure-storage-common
* Increment package version after release of azure-storage-blobs
* Increment package version after release of azure-storage-files-datalake
* Increment package version after release of azure-storage-files-shares
* Revert the ordering change for beta.6.
Co-authored-by: Ahson Khan <ahkha@microsoft.com>
Co-authored-by: Ahson Khan <ahson_ahmedk@yahoo.com>
* Fix the date in the changelog for storage beta.6 packages using the correct year to avoid auto version bump PR re-ordering it
* Fix the year for common beta.6
* Fix the CL year for shares beta.6
* Fix the CL year for datalake beta.6
* Update storage datalake CL to group changes to return types together
* Remove DataLake from the return types in CL
* Update CL for file shares to be accurate
* Fix file shares GetProperties breaking changes
# Pull Request Checklist
Please leverage this checklist as a reminder to address commonly occurring feedback when submitting a pull request to make sure your PR can be reviewed quickly:
See the detailed list in the [contributing guide](https://github.com/Azure/azure-sdk-for-cpp/blob/master/CONTRIBUTING.md#pull-requests).
- [x] [C++ Guidelines](https://azure.github.io/azure-sdk/cpp_introduction.html)
- [x] Doxygen docs
- [x] Unit tests
- [x] No unwanted commits/changes
- [x] Descriptive title/description
- [x] PR is single purpose
- [x] Related issue listed
- [x] Comments in source
- [x] No typos
- [x] Update changelog
- [x] Not work-in-progress
- [x] External references or docs updated
- [x] Self review of PR done
- [x] Any breaking changes?
closes https://github.com/Azure/azure-sdk-for-cpp/issues/1869
# Pull Request Checklist
Please leverage this checklist as a reminder to address commonly occurring feedback when submitting a pull request to make sure your PR can be reviewed quickly:
See the detailed list in the [contributing guide](https://github.com/Azure/azure-sdk-for-cpp/blob/master/CONTRIBUTING.md#pull-requests).
- [x] [C++ Guidelines](https://azure.github.io/azure-sdk/cpp_introduction.html)
- [x] Doxygen docs
- [x] Unit tests
- [x] No unwanted commits/changes
- [x] Descriptive title/description
- [x] PR is single purpose
- [x] Related issue listed
- [x] Comments in source
- [x] No typos
- [x] Update changelog
- [x] Not work-in-progress
- [x] External references or docs updated
- [x] Self review of PR done
- [x] Any breaking changes?
* Move changelog entry to correct place
* Reformat breaking changes
* New feature in the right place
* body_stream.hpp
* Backtick
* Add changes made for Context
* More updates
* More updates
Co-authored-by: Anton Kolesnyk <antkmsft@users.noreply.github.com>
* Moved the `Base64Encode()` and `Base64Decode()` functions to be static members of a `Convert` class within the `Azure::Core` namespace.
* Add the class name in the source file for posix.
Usability studies found that static methods are generally not as user-friendly as instance methods. Folks new to the SDK have harder time discovering the APIs, they reverse the flow of typing, and the calling code ends up a bit more verbose because you have to spell out the whole namespace and type name when there aren't any using directives.
There doesn't seem to be a strong benefit or feasibility reason to keep these method statics which are typically harder to use and discover.
cc @kyle-patterson
