Sitelet https://github.com/benbjohnson/immutable/pull/39
Skip to content

Ensure immutability of sets, maps & lists - #39

Merged
benbjohnson merged 4 commits into
benbjohnson:masterfrom
BarrensZeppelin:fix-sets
Jan 18, 2023
Merged

benbjohnson merged 4 commits into
benbjohnson:masterfrom
BarrensZeppelin:fix-sets

Conversation

@BarrensZeppelin

Copy link
Copy Markdown
Contributor

As I wrote in #32 (comment) the current implementation of sets is broken, as well as the SetMany implementations.
It is not safe to perform updates with mutable=true after calling clone().

@laher laher left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Good catch. Not enough tests on my part, sorry.

I'd do this a little differently though, to avoid the creation of a new immutable.Map / immutable.Set for each item. I think initialising the new Sets with s.Items()... could be quite nice in this case.

For Map.SetMany I'd do something similar to the existing Map.set(), but with a for loop. I could offer another solution in a day or two for the maps in particular. I could also add more tests.

FWIW I think it's probably fine to merge this PR for correctness, and then merge my changes later.

Comment thread sets.go
Comment thread sets.go Outdated
Comment thread README.md
Comment thread immutable.go Outdated
@laher laher mentioned this pull request Jan 11, 2023

@laher laher left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

This is the best way, for the time being. Sorry I didn't realise Maps were so stateful when I PR'd the varargs changes.

Aside: I wonder if we should revert Set.Set() to being non-varargs, and to remove Map.SetMany(). They are convenient, but IMO unexpectedly greedy. MapOf() and NewSet() both support efficient putting of multiple items, and I figure that's enough.

@BarrensZeppelin

Copy link
Copy Markdown
Contributor Author

No worries. 🙂

I agree with the API changes. If the user wants those conveniences, they're simple enough to implement on the side.
Do you prefer that I update this PR, or would you rather have it in a separate one?

@laher

laher commented Jan 12, 2023

Copy link
Copy Markdown
Contributor

Do you prefer that I update this PR, or would you rather have it in a separate one?

Up to you, whatever you prefer. (BTW I don't have any authority on this repo, I'm just a random)

@BarrensZeppelin
BarrensZeppelin marked this pull request as draft January 12, 2023 09:24
@BarrensZeppelin BarrensZeppelin changed the title Ensure immutability of sets Ensure immutability of sets, maps & lists Jan 12, 2023
The implementation behind the API is not more efficient than manually
looping over a data structure and inserting elements one-by-one.
Similar reason for the API change as the previous commit.
The closure passed to t.Run captured the loop variable which would
always be equal to `*randomN` once the tests started running. This meant
that all of the runs used the same random seed.
@BarrensZeppelin
BarrensZeppelin marked this pull request as ready for review January 12, 2023 10:02
@BarrensZeppelin

Copy link
Copy Markdown
Contributor Author

The Append and Prepend methods of lists were also doing unsound mutable updates.

Since these updated functions have already been published in v0.4.2, it might be a good idea to mark that version of the library as retracted? @benbjohnson

@benbjohnson

Copy link
Copy Markdown
Owner

@BarrensZeppelin Sorry for the delay in reviewing this. Looks good. Thanks for catching this. I'll retract v0.4.2.

@benbjohnson
benbjohnson merged commit d6cf261 into benbjohnson:master Jan 18, 2023
@benbjohnson benbjohnson mentioned this pull request Jan 18, 2023
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.

3 participants