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

Relax mutability requirements for Fluvio Admin client #1178

Closed
nicholastmosher opened this issue Jun 18, 2021 · 0 comments
Closed

Relax mutability requirements for Fluvio Admin client #1178

nicholastmosher opened this issue Jun 18, 2021 · 0 comments
Assignees

Comments

@nicholastmosher
Copy link
Contributor

Right now, the methods on the FluvioAdmin client all take &mut self reference:

impl AdminClient {
    pub async fn create<...>(&mut self, ...) { ... }
    pub async fn delete<...>(&mut self, ...) { ... }
    pub async fn list<...>(&mut self, ...) { ... }
}

However, after digging around a little bit, I discovered that these methods do not actually require mutable access to any internal state (everything is already synchronized), so we can actually relax these methods to take &self.

impl AdminClient {
    pub async fn create<...>(&self, ...) { ... }
    pub async fn delete<...>(&self, ...) { ... }
    pub async fn list<...>(&self, ...) { ... }
}

This will be helpful for use-cases like the fluvio-client-wasm wrapper around the Admin API, because we can reduce the wrapper code from Rc<RefCell<FluvioAdmin>> (which is currently causing panics due to multiple borrowing of RefCell) down to Rc<FluvioAdmin>.

@nicholastmosher nicholastmosher self-assigned this Jun 18, 2021
bors bot pushed a commit that referenced this issue Jun 18, 2021
Closes #1178. Will help to prevent bugs like infinyon/fluvio-client-wasm#42

- Changes `&mut self` to `&self` for `create`, `delete`, and `list` methods on `FluvioAdmin`.
@bors bors bot closed this as completed in f39482b Jun 18, 2021
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 a pull request may close this issue.

1 participant