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
Member

@jnyrup 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
Copy link
Member

  • 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
Copy link
Member 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
Copy link
Member 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
Copy link
Member 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
@jnyrup jnyrup deleted the SatisfyRespectively branch December 12, 2019 11:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

StringCollectionAssertions missing SatisfyRespectively GenericCollectionAssertions
2 participants