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

Is there any reason not to merge MemGroup and MemDiskGroup? #115

Open
nritsche opened this issue Mar 3, 2020 · 1 comment
Open

Is there any reason not to merge MemGroup and MemDiskGroup? #115

nritsche opened this issue Mar 3, 2020 · 1 comment
Assignees
Labels

Comments

@nritsche
Copy link
Contributor

nritsche commented Mar 3, 2020

@kiyo-masui after you had good arguments against the last proposal of changing the design, I'm hoping to get your opinion once again.

According to @jrs65 there's no good reason anymore to keep MemGroup and MemDiskGroup two separate classes.

@nritsche nritsche self-assigned this Mar 3, 2020
@kiyo-masui
Copy link
Contributor

I think it might be doable, but with significant labor. MemGroup exposes the same API as an HDF5 Group, but with the underlying storage in a tree of dictionaries. MemDiskGroup exposes the same API again, but is agnostic to whether the underlying storage is a MemGroup or an HDF5 Group (and then adds a bunch of functionality on top). I think it should work to merge the memory-specific code right into MemDiskGroup though.

I don't think there are compatibility reasons not to do away with MemGroup. We can provide a stub (MemGroup = MemDiskGroup) for compatibility, and they provide the same API.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants