## Fixes#3519
<!-- Add the relevant issue number after the "#" mentioned above (for ex: Fixes#1234) which will automatically close the issue once the PR is merged. -->
<!-- Add a brief overview here of the feature/bug & fix. -->
Removes two restrictions from `ObservableGroup` to make it usable in more situations. In my case, I wanted to be able to rename the groups (for this I needed a mutable key), and I wanted to add properties on the group level (I needed to unseal it)
- Removes the immutable restriction on the `Key` property and makes the `Key` property observable.
- Removes the `sealed` keyword from `ObservableGroup`
## PR Type
What kind of change does this PR introduce?
<!-- Please uncomment one or more that apply to this PR. -->
<!-- - Bugfix -->
- Feature
<!-- - Code style update (formatting) -->
<!-- - Refactoring (no functional changes, no api changes) -->
<!-- - Build or CI related changes -->
<!-- - Documentation content changes -->
<!-- - Sample app changes -->
<!-- - Other... Please describe: -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying, or link to a relevant issue. -->
`ObservableGroup` has an immutable `Key` property
`ObservableGroup` is not inheritable
## What is the new behavior?
<!-- Describe how was this issue resolved or changed? -->
`ObservableGroup` has a mutable `Key` property
`ObservableGroup` is inheritable
## PR Checklist
Please check if your PR fulfills the following requirements:
- [ ] Tested code with current [supported SDKs](../readme.md#supported)
- [x] Pull Request has been submitted to the documentation repository [instructions](..\contributing.md#docs). Link: https://github.com/MicrosoftDocs/WindowsCommunityToolkitDocs/pull/394
- [x] Sample in sample app has been added / updated (for bug fixes / features) --> _no update needed_
- [x] Icon has been created (if new sample) following the [Thumbnail Style Guide and templates](https://github.com/windows-toolkit/WindowsCommunityToolkit-design-assets) --> _not applicable_
- [x] Tests for the changes have been added (for bug fixes / features) (if applicable) --> _not applicable_
- [x] Header has been added to all new source files (run *build/UpdateHeaders.bat*) --> _not applicable_
- [ ] Contains **NO** breaking changes
<!-- If this PR contains a breaking change, please describe the impact and migration path for existing applications below.
Please note that breaking changes are likely to be rejected. -->
## Other information
## PR type:
What kind of change does this PR introduce?
<!-- Please uncomment one or more that apply to this PR. -->
- Performance improvement
<!-- - Bugfix -->
<!-- - Feature -->
<!-- - Code style update (formatting) -->
<!-- - Refactoring (no functional changes, no api changes) -->
<!-- - Build or CI related changes -->
<!-- - Documentation content changes -->
<!-- - Sample app changes -->
<!-- - Other... Please describe: -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying, or link to a relevant issue. -->
The `MemoryStream` type wraps a `Memory<byte>` instance, so every time a read/write operation needs to be performed, it will need to use `Memory<T>.Span`, which is relatively expensive to invoke, as it needs to handle multiple possible sources of data. We can use generic types and the value delegate trick (constrained generic struct + interface) to optimize this away.
## What is the new behavior?
<!-- Describe how was this issue resolved or changed? -->
We now use a `MemoryStream<TSource>` type (which is internal anyway) and have a bunch of `IMemorySource` types specifically supporting `byte[]` and `MemoryManager<byte>` sources with additional optimizations wherever possible. Also, just using this already removes all the overhead of dynamically creating a `Span<T>` from the wrapped `Memory<T>` instance.
Here's a benchmark I put together to show the before/after:
The benchmark consists of writing 1024 times a 1024 bytes buffer to a target `Stream` instance.
The new `MemoryStream<TSource>` version is almost 25% faster just thanks to this change 🚀
## PR Checklist
Please check if your PR fulfills the following requirements:
- [X] Tested code with current [supported SDKs](../readme.md#supported)
- [ ] ~~Pull Request has been submitted to the documentation repository [instructions](..\contributing.md#docs).~~
- [ ] ~~Sample in sample app has been added / updated (for bug fixes / features)~~
- [ ] ~~Icon has been created (if new sample) following the [Thumbnail Style Guide and templates](https://github.com/windows-toolkit/WindowsCommunityToolkit-design-assets)~~
- [X] Tests for the changes have been added (for bug fixes / features) (if applicable)
- [X] Header has been added to all new source files (run *build/UpdateHeaders.bat*)
- [X] Contains **NO** breaking changes
## Overview
Some `Guard` APIs were incorrectly using the wrong capitalization for the `WhiteSpace` part, not following the same structure of the actual APIs in the BCL (eg. `string.IsNullOrWhiteSpace`). This PR deprecates them and adds new APIs with the right name.
...I'm sorry 😅
<!-- Add a brief overview here of the feature/bug & fix. -->
## PR Type
What kind of change does this PR introduce?
<!-- Please uncomment one or more that apply to this PR. -->
- API rename
- API deprecation
## PR Checklist
Please check if your PR fulfills the following requirements:
- [X] Tested code with current [supported SDKs](../readme.md#supported)
- [ ] ~~Pull Request has been submitted to the documentation repository [instructions](..\contributing.md#docs). Link: <!-- docs PR link -->~~
- [ ] ~~Sample in sample app has been added / updated (for bug fixes / features)~~
- [ ] ~~Icon has been created (if new sample) following the [Thumbnail Style Guide and templates](https://github.com/windows-toolkit/WindowsCommunityToolkit-design-assets)~~
- [ ] ~~Tests for the changes have been added (for bug fixes / features) (if applicable)~~
- [ ] ~~Header has been added to all new source files (run *build/UpdateHeaders.bat*)~~
- [X] Contains **NO** breaking changes
Sergio Pedri
