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

Add Reject operation. #125

Merged
merged 8 commits into from
Jul 7, 2021
Merged

Add Reject operation. #125

merged 8 commits into from
Jul 7, 2021

Conversation

drupol
Copy link
Collaborator

@drupol drupol commented Jul 6, 2021

This PR

  • Add a new operation Reject.
  • Has tests
  • Has documentation
  • Has static analysis tests

Depends on #126
Related to #123

@drupol drupol added the enhancement New feature or request label Jul 6, 2021
@drupol drupol force-pushed the feature/add-reject-operation branch from bfa1f7f to cb8ef1e Compare July 6, 2021 17:02
@drupol drupol changed the base branch from master to refactor-update-filter-operation July 6, 2021 17:02
@drupol drupol force-pushed the feature/add-reject-operation branch from cb8ef1e to c796e59 Compare July 6, 2021 17:06
@drupol drupol changed the title Add Reject operation. Add Reject operation. Jul 6, 2021
@drupol drupol requested a review from AlexandruGG July 6, 2021 19:54
@drupol drupol marked this pull request as ready for review July 6, 2021 19:57
Base automatically changed from refactor-update-filter-operation to master July 6, 2021 21:09
@AlexandruGG
Copy link
Collaborator

@drupol if you solve the conflicts here I can give this one a good look as well

@drupol drupol force-pushed the feature/add-reject-operation branch from c796e59 to 2b8a228 Compare July 6, 2021 21:13
@drupol
Copy link
Collaborator Author

drupol commented Jul 6, 2021

Rebased and ready to review!

reject_checkMap(Collection::fromIterable(['foo' => 'bar', 'baz' => ''])->filter($stringValueCallback, $stringValueCallback2));
reject_checkMap(Collection::fromIterable(['foo' => 'bar', 'baz' => ''])->filter($stringKeyValueCallback1));
reject_checkMap(Collection::fromIterable(['foo' => 'bar', 'baz' => ''])->filter($stringKeyValueCallback1, $stringKeyValueCallback2));
reject_checkList(Collection::fromIterable([1, 2, 3])->reject());
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#facepalm ... I should more careful sometimes !

src/Operation/Reject.php Outdated Show resolved Hide resolved
@AlexandruGG AlexandruGG force-pushed the feature/add-reject-operation branch from 376f2b8 to 71d0732 Compare July 6, 2021 21:36
Comment on lines +22 to +27
$collection = Collection::fromIterable(range(1, 10))
->reject($divisibleBy2, $divisibleBy3); // [1, 5, 7]

$collection = Collection::fromIterable(range(1, 10))
->reject($divisibleBy2)
->reject($divisibleBy3); // [1, 5, 7]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is it just me or because of the nature of reject, calling it with variadic callbacks is the same as calling it multiple times? Acts as logical AND

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes exactly !

Not "A or B" is "Not A and Not B"

Copy link
Collaborator

@AlexandruGG AlexandruGG left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is missing tests 😉

@drupol
Copy link
Collaborator Author

drupol commented Jul 6, 2021

This is missing tests wink

Going to do this tomorrow, I'm out for today.

@AlexandruGG
Copy link
Collaborator

This is missing tests 😉

On this, I was surprised nothing in the CI workflows alerted us about it. But now I see there's nothing in the workflows to cause it to fail if a certain code coverage % is not reached. Would you want to have something like that?

Another two things I noticed looking into the jobs 😄

  1. this is broken

Screenshot 2021-07-06 at 22 53 34

  1. we are running the jobs twice, it would be sufficient to either trigger them on pull_request OR on push

Screenshot 2021-07-06 at 22 54 30

I can create a separate PR to fix number 2, but not too sure about number 1

@drupol drupol force-pushed the feature/add-reject-operation branch from 71d0732 to 99c12d3 Compare July 7, 2021 06:56
@drupol
Copy link
Collaborator Author

drupol commented Jul 7, 2021

This is missing tests wink

On this, I was surprised nothing in the CI workflows alerted us about it. But now I see there's nothing in the workflows to cause it to fail if a certain code coverage % is not reached. Would you want to have something like that?

Yes good idea and it's quite easy to do, it's already done here: https://github.com/ecphp/cas-bundle/blob/master/grumphp.yml.dist#L9

Another two things I noticed looking into the jobs smile

1. this is broken
Screenshot 2021-07-06 at 22 53 34

Yes this is broken on Windows, and it's "normal". This step is only supposed to be triggered on Linux. This is also why continue-on-error: true is there.

1. we are running the jobs twice, it would be sufficient to either trigger them on `pull_request` OR on `push`
Screenshot 2021-07-06 at 22 54 30

Yeah I think that could be fixed in a separate PR indeed.

@AlexandruGG
Copy link
Collaborator

On this, I was surprised nothing in the CI workflows alerted us about it. But now I see there's nothing in the workflows to cause it to fail if a certain code coverage % is not reached. Would you want to have something like that?

Yes good idea and it's quite easy to do, it's already done here: https://github.com/ecphp/cas-bundle/blob/master/grumphp.yml.dist#L9

on this, does it mean that the coverage check is already enforced but the level (80%) is too low so that's why it didn't fail?

@drupol
Copy link
Collaborator Author

drupol commented Jul 7, 2021

On this, I was surprised nothing in the CI workflows alerted us about it. But now I see there's nothing in the workflows to cause it to fail if a certain code coverage % is not reached. Would you want to have something like that?

Yes good idea and it's quite easy to do, it's already done here: https://github.com/ecphp/cas-bundle/blob/master/grumphp.yml.dist#L9

on this, does it mean that the coverage check is already enforced but the level (80%) is too low so that's why it didn't fail?

That's for ecphp/cas-bundle project 😄 !

@AlexandruGG
Copy link
Collaborator

On this, I was surprised nothing in the CI workflows alerted us about it. But now I see there's nothing in the workflows to cause it to fail if a certain code coverage % is not reached. Would you want to have something like that?

Yes good idea and it's quite easy to do, it's already done here: https://github.com/ecphp/cas-bundle/blob/master/grumphp.yml.dist#L9

on this, does it mean that the coverage check is already enforced but the level (80%) is too low so that's why it didn't fail?

That's for ecphp/cas-bundle project 😄 !

Oops misread it, I thought it was on the php-conventions project 😄

@drupol drupol merged commit a065b1c into master Jul 7, 2021
@drupol drupol deleted the feature/add-reject-operation branch July 7, 2021 08:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants