Skip to content

Support SatisfyRespectively for string collections #1201

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.

Sign up for GitHub

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

Jump to bottom
Merged
jnyrup merged 1 commit into from
Dec 12, 2019
Merged

Support SatisfyRespectively for string collections #1201

jnyrup 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

@jnyrup
Support SatisfyRespectively for string collections
3acfc5e 
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

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
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

Reviewers

@dennisdoomen dennisdoomen dennisdoomen approved these changes

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

StringCollectionAssertions missing SatisfyRespectively GenericCollectionAssertions

2 participants

@jnyrup @dennisdoomen