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

Plumb Silencer.new and use it #542 spec #544

Merged

Conversation

ColinDKelley
Copy link
Collaborator

  • Use explicit ignore!: [/\A\.ignored/] silencer option in record_spec so we're not depending on Silencer's defaults.
  • Update Silencer to allow its config to be passed into initialize rather than mutated by configure. Update some comments there about deprecating mutation.
  • Update a few stubs that no longer matched.

@ColinDKelley
Copy link
Collaborator Author

@ElMassimo Here's the follow-up PR from #542. Look good?

@ColinDKelley ColinDKelley force-pushed the plumb-silencer-new-and-use-it-#542-spec branch from ffc0608 to 2750b38 Compare August 14, 2021 22:04
@ElMassimo
Copy link
Contributor

ElMassimo commented Aug 14, 2021

Excellent, thanks Colin!

@ColinDKelley ColinDKelley changed the title Plumb silencer new and use it #542 spec Plumb Silencer.new and use it #542 spec Aug 15, 2021
@ColinDKelley
Copy link
Collaborator Author

Merging this now since few tests are broken without it.

@ColinDKelley ColinDKelley merged commit 306a8bc into guard:master Aug 15, 2021
@ColinDKelley ColinDKelley deleted the plumb-silencer-new-and-use-it-#542-spec branch August 15, 2021 10:42
@ColinDKelley
Copy link
Collaborator Author

BTW, I'm expecting to release this in v3.7.0 in the coming week.

attr_accessor :only_patterns, :ignore_patterns

def initialize
configure({})
def initialize(options = {})
Copy link
Member

Choose a reason for hiding this comment

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

I'm not sure the backwards compatibility constraints but you should prefer **options.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

All previous cases initialized this object with no arguments, so I don't think there's a concern there.

Can you help me understand what cases will work better with **options vs. options = {}?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I know that **options is effective at collecting the options hash as the last argument when there are many arguments. But with a single argument like this, I'm not seeing a difference between **options and options = {}?

Copy link
Collaborator Author

@ColinDKelley ColinDKelley Aug 18, 2021

Choose a reason for hiding this comment

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

Maybe **options is preferred because it always works regardless of other arguments before it?
I switched over to it here: 32bb3a7

Copy link
Member

@ioquatix ioquatix left a comment

Choose a reason for hiding this comment

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

LGTM.

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.

3 participants