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

storage: add 'RWStorage' grouping interface. #277

Closed
wants to merge 1 commit into from

Conversation

warpfork
Copy link
Collaborator

Feedback requested. I'm dubious about this one.

I've sometimes felt the desire to make a constructor function that -- like the doc in the diff describes -- returns an interface, not a concrete type, and happens to implement both the reading and the writing features at the same time. Then, one wants that type to also be immediately ready to pass to any of the other functions that expect ReadableStorage or WritableStorage. This combined interface would allow that.

On the other hand: this feels weird, because I spent >50% of the docs text saying when one shouldn't use this interface. Maybe we shouldn't introduce this interface, and instead should provide documentation recommending a pattern of func MyRWConstructor(...your params here...) (ReadableStorage, WritableStorage, error) that uses multiple returns in a way that's symmetric to how we pass them around separately elsewhere.

Thoughts?

@warpfork
Copy link
Collaborator Author

warpfork commented Oct 24, 2021

I've come to think this is a bad idea.

The func MyRWConstructor(...your params here...) (ReadableStorage, WritableStorage, error) pattern is a better idea.

I'm gonna drop this diff.

@warpfork warpfork closed this Oct 24, 2021
@warpfork warpfork deleted the storage-api-rw branch October 24, 2021 11:45
warpfork added a commit that referenced this pull request Oct 25, 2021
I came to see this as avoidable; and the fact that >50% of the docs on
the type were admonishments about when _not_ to use it was a bad sign.

This pattern could be a way to use to avoid needing a RW interface:
`func MyRWConstructor(...your params here...) (ReadableStorage, WritableStorage, error)`.
Or in other words: using multiple returns, each with the relevant type,
keeps things nicely similar to how we'll expect to continue passing
them around separately thereafter.

Also briefly discussed as a PR at
#277 .
@willscott
Copy link
Member

I think I'd like to have a single object so that it's clear that it's the same store that where reads after writes will reflect what was written earlier.

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