-
Notifications
You must be signed in to change notification settings - Fork 100
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
A StableBuffer
module.
#299
base: master
Are you sure you want to change the base?
Conversation
It might be worth making |
Yeah, seems like a good idea, to the extent that we can do this. It's nearly possible to do it fully, except in the binary operation cases, where it is not (since there is no way to coerce the |
Next step is to adapt the tests. Then ready for review. (But anyone is welcome to look now, too) |
Presumably the stable buffer would be a |
Good questions --- Yeah, if we get rid of the data abstraction (at least exposing the representation to those clients that want to look) then I think the earlier impasse could vanish, yes. Seems like a perfect compromise: " Both sides" get something, but also give something up.* BTW, do you fancy the FWIW, seems like the accessor version at least maintains some semblance of abstraction.** *, ** : Though it really doesn't, since the accessor would also expose implementation details by exposing the part of the |
This PR has a complete module and test now. It's ready for review. However, since starting the PR, @nomeata and I agreed that more work should follow soon:
I'll save those tasks for separate PRs. |
Are we happy with the name? Maybe something more succinct to encourage it's use (assuming we don't want to take over the existing |
I'm not satisfied with the name. Yeah, perhaps this should be called WDYT @rossberg ? FWIW, I am recalling why we went with the OO API for the Another thought I had was to use the path structure of |
|
Oh, right about the |
Really? I have heard of a stable algorithm (like "stable sorting"), but not much of stable data structures. Motoko already has given this word some extra attention, by using it as a keyword (in the role that we mean here). |
It's not a popular term, but the same concept can be applied to data structures, for example: https://ece.uwaterloo.ca/~dwharder/aads/Projects/4/Stable_binary_heap/#:~:text=A%20heap%20is%20said%20to,were%20placed%20into%20the%20heap. SAC also has a concept of stability, and we call it retroactive data structures. But it can be called as "stable data structures" :) My main point is that the name for a data structure module specifies the property of the data structure, but |
But it’s not |
How about "cumbersome" instead of "stable"?
They are "cumbersome" because:
Of course, the word "cumbersome" is itself too cumbersome! Alas! |
How about this idiom: For
and used like this:
This way:
|
I like that idiom, and it matches my existing intuitions about how the layers of the Motoko PL naturally give rise to layers in each data structure's module, as you suggest. But where you wrote |
Yeah, object or class, don't make a big difference to me |
In another PR, for
Just to make the non-OO code ergonomic, I found myself introducing two record types, one is stable (like your Have a look if you're curious, and feel free to comment there, even thought it's still "draft". If this module were to also give the OO interface as well, as you propose, I think there'd be a need for a third type, for the |
I think it is! Or rather, it'd be the encapsulated immutable state of the OO-style class, so it wouldn't show up as a type of its own. And all operations would be class ops and have easy access to these parameters. I don't think you'd explicitly give it a type, though. |
this is to demonstrate what I meant in dfinity#300 (comment) and dfinity#299 (comment), and how to introduce this without breaking changes (although it’s kinda ugly) What I would _want_ here is to introduce a second, more general, constructor for the given class, but Motoko does not allow me to do that easily. But I can hack around that by * Creating a new class, not public `HashMap_` with the constructor I want * In `HashMap`’s constructor, call the `HashMap_` constructor to create an inner object (`i`) * In `HashMap`, simply copy all the fields from the inner objects to the outer object. * A public module-level function (here `wrapS`) exposes the new constructor. With this (generic, ugly) trick I can suppor the idiom ``` stable var userS : HashMap.S <UserId,UserData> = newS(); let user : HashMap.HashMap<UserId,UserData> = HashMap.wrapS(10, Nat.eq, Nat.hash, userS) ``` without changing the API. But it is ugly, and the effect on documentation generation is probably bad as well. So maybe a better course of action would be to have a midly breaking change where we only have the “new” constructor, and people will have to fix their code by passing `HashMap.newS()` as a new fourth argument if they want their old behavior. Probably better than piling up hacks like this. In that case, simply rename `class HashMap_` to `HashMap`, remove `wrapS` and the old `class HashMap`.
See #301 for how to achieve this without new modules |
d52aecd
to
08507fc
Compare
Addresses #298