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

client: unexport the watcher type and update NewUpdater #118

Merged
merged 1 commit into from
Sep 24, 2024

Conversation

creachadair
Copy link
Member

@creachadair creachadair commented Aug 22, 2024

The watcher semantics are still useful for plumbing, but it's hard to use
correctly, so unexport it. Now that watcher is unexported, move its tests from
a separate package into an internal package test.

It is now no longer necessary to have the "watcher" method, so remove it.

An Updater now no longer accepts a watcher (which is unexported), but instead
takes a *Store and the desired secret name directly. Rework the constructor to
allow reporting an error.

Add a StaticUpdater constructor to make an Updater that vends a static value,
analogous to StaticSecret.

Copy link
Member

@danderson danderson left a comment

Choose a reason for hiding this comment

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

Does each intermediate commit build, with this order of unexporting before changing NewUpdater's signature? Obviously NewUpdater becomes unusable in one of the intermediate commits until a later one, but as long as each commit builds that seems okay.

(I'm trying to work out whether you can rebase-and-merge or whether you should squash-and-merge, to try and keep all commits in the history buildable where possible)

Either way, LGTM!

@creachadair

This comment was marked as resolved.

@creachadair creachadair force-pushed the mjf/simplifex branch 2 times, most recently from f717e7b to 60ca42f Compare September 12, 2024 23:46
@creachadair creachadair marked this pull request as draft September 12, 2024 23:54
@creachadair

This comment was marked as resolved.

The watcher semantics are still useful for plumbing, but it's hard to use
correctly, so unexport it.  Now that watcher is unexported, move its tests from
a separate package into an internal package test.

It is now no longer necessary to have the "watcher" method, so remove it.

An Updater now no longer accepts a watcher (which is unexported), but instead
takes a *Store and the desired secret name directly. Rework the constructor to
allow reporting an error.

Add a StaticUpdater constructor to make an Updater that vends a static value,
analogous to StaticSecret.
@creachadair creachadair changed the title Simplify the API of the Store type client: unexport the watcher type and update NewUpdater Sep 24, 2024
Copy link
Member Author

Choose a reason for hiding this comment

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

This test is moved from store_test.go, so that it can test the now-unexported type.

@@ -291,71 +287,6 @@ func TestSlowInit(t *testing.T) {
checkSecretValue(t, st, "boo", "go for the eyes")
}

func TestWatcher(t *testing.T) {
Copy link
Member Author

Choose a reason for hiding this comment

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

Moved to internal_test.go

Copy link
Member Author

Choose a reason for hiding this comment

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

Moved from store.go, and unexported.

@creachadair creachadair marked this pull request as ready for review September 24, 2024 18:08
@creachadair
Copy link
Member Author

@danderson This is (finally) ready for another look, I had to go make sure I could port the existing use cases and in doing so discovered more was needed.

// The value reported by the updater never changes.
func StaticUpdater[T any](fixedValue T) *Updater[T] {
return &Updater[T]{
newValue: panicOnUpdate[T],
Copy link
Member

Choose a reason for hiding this comment

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

To be sure I understand: barring a bug in this library, this should never get called, correct? In particular, there's no way for a user of this library to hold things wrong enough to trigger the panic?

Copy link
Member Author

Choose a reason for hiding this comment

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

That is correct—the only way that could happen is if a new secret value were delivered, which cannot happen as there is no Store. This is mainly here as documentation.

@creachadair creachadair merged commit 66c76d4 into main Sep 24, 2024
1 check passed
@creachadair creachadair deleted the mjf/simplifex branch September 24, 2024 18:20
creachadair added a commit that referenced this pull request Sep 28, 2024
creachadair added a commit that referenced this pull request Sep 28, 2024
creachadair added a commit that referenced this pull request Sep 28, 2024
creachadair added a commit that referenced this pull request Sep 30, 2024
creachadair added a commit that referenced this pull request Nov 4, 2024
creachadair added a commit that referenced this pull request Nov 7, 2024
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.

2 participants