You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Second, (and please correct me if I missed something!) it does not leave a possibility for customization. I think the set and map modules should be parameterized on a tuple of hash and equals. A default can be provided for convenience.
The text was updated successfully, but these errors were encountered:
Hey, really sorry about the slow reply. I foolishly read the issue on my phone before going to sleep, and then forgot to follow up.
The HashMap collection was actually ported from another package (see the contributor credits), and the intent was to upgrade the hashing function there to use what's in the core library. It hasn't come up as an issue for me yet though, which is why it's remained on the backburner. I'm open to pull requests on this one. Note that what's in the core library should be ok in theory, but again if you see any issues there, I'm very much open to contributions that help me improve things. This project is very much alive, despite the apparent long periods of inactivity - I just have several projects I'm working on in tandem, and being just one person, I only have so much productive bandwidth to allocate at any given time.
I was looking through the source and found that the hash function is quite simple:
I can see two problems that might occur with this.
First,
JSON.stringify
can be sensitive to property order, which might lead to unexpected behaviour:Second, (and please correct me if I missed something!) it does not leave a possibility for customization. I think the set and map modules should be parameterized on a tuple of
hash
andequals
. A default can be provided for convenience.The text was updated successfully, but these errors were encountered: