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

Support `SatisfyRespectively` for string collections #1201

Merged
merged 1 commit into from Dec 12, 2019

Conversation

@jnyrup
Copy link
Collaborator

jnyrup commented Dec 8, 2019

By moving SatisfyRespectively from GenericCollectionAssertions to SelfReferencingCollectionAssertions we enable string collections to re-use the same assertions.

To the best of my knowledge, this should not be a breaking change.

  • Moving members to parent class is not a breaking change

  • The return type has changed from AndConstraint<GenericCollectionAssertions<T>> to AndConstraint<TAssertions>, but for GenericCollectionAssertions<T> TAssertions is exactly GenericCollectionAssertions<T>.

This fixes #1188

By moving `SatisfyRespectively` from `GenericCollectionAssertions` to `SelfReferencingCollectionAssertions`  we enable string collections to re-use the same assertions.

To the best of my knowledge, this should not be a breaking change.

* Moving members to parent class is not a breaking change

* The return type has changed from `AndConstraint<GenericCollectionAssertions<T>>` to `AndConstraint<TAssertions>`, but for `GenericCollectionAssertions<T>` `TAssertions` *is* exactly `GenericCollectionAssertions<T>`.
@dennisdoomen

This comment has been minimized.

Copy link
Member

dennisdoomen commented Dec 9, 2019

  • The return type has changed from AndConstraint<GenericCollectionAssertions<T>> to AndConstraint<TAssertions>, but for GenericCollectionAssertions<T> TAssertions is exactly GenericCollectionAssertions<T>.

Isn't changing the return type always a breaking change?

@jnyrup

This comment has been minimized.

Copy link
Collaborator Author

jnyrup commented Dec 9, 2019

Hmm... You're probably right.
I'll change it to have be in both GenericCollectionAssertions<T> and StringCollectionAssertions for now.
Can consolidate it in 6.0

@jnyrup

This comment has been minimized.

Copy link
Collaborator Author

jnyrup commented Dec 12, 2019

Pulling SatisfyRespectively up into SelfReferencingCollectionAssertions is not a breaking change.
Asked on SO and got an answer from Eric Lippert himself.
https://stackoverflow.com/questions/59255869/is-pulling-up-a-method-into-a-generic-base-class-a-breaking-change#comment104785181_59257698

@jnyrup

This comment has been minimized.

Copy link
Collaborator Author

jnyrup commented Dec 12, 2019

The return type of GenericCollectionAssertions<T>.SatisfyRespectively does not change as:

  • SelfReferencingCollectionAssertions<T, TAssertions>.SatisfyRespectively returns AndConstraint<TAssertions>
  • GenericCollectionAssertions<T> derives from SelfReferencingCollectionAssertions<T, GenericCollectionAssertions<T>>
  • So GenericCollectionAssertions<T>.SatisfyRespectively will still return AndConstraint<GenericCollectionAssertions<T>>

I asked the question on SO and got an answer from Eric Lippert himself.
https://stackoverflow.com/questions/59255869/is-pulling-up-a-method-into-a-generic-base-class-a-breaking-change/59257698#59257698

@jnyrup jnyrup merged commit 1a87adb into fluentassertions:master Dec 12, 2019
1 check passed
1 check passed
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
@jnyrup jnyrup deleted the jnyrup:SatisfyRespectively branch Dec 12, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.