Functions / closures are not Hashable

[rakudrama]

I have a program that walks a datastructure that contains various objects including functions and needs to detect if the same object / function (f1 === f2) occurs twice.

I can't do this with HashMap for several reasons:

1. Closures don't implement Hashable and don't have a hashCode() method.
2. Even if they did, some objects that do implement Hashable also implement ==, but I want to hash on object identity, not object-defined equivalence.

I would be happy with
(a) A HashMap that takes the hash function and equivalence as a parameter
(b) a way of generating a hash code for closures.

[DartBot]

This comment was originally written by drfibonacci@google.com

---

Added Area-Language, Triaged labels.

[gbracha]

Set owner to @gbracha.
Added Accepted label.

[DartBot]

This comment was originally written by jacob314...@gmail.com

---

This would be very useful when implementing observable objects.

[anders-sandholm]

Added apr30-triage label.

[anders-sandholm]

Removed apr30-triage label.

[anders-sandholm]

Added triage1 label.

[anders-sandholm]

Removed triage1 label.
Added Duplicate label.
Marked as being merged into #144.

[gbracha]

Resurrecting this as a library question, since 144 of which this was considered a duplicate) is closed.

---

Removed Area-Language label.
Added Area-Library, Triaged labels.
Marked as being merged into #.

[gbracha]

Removed the owner.

[lrhn]

The request is for either
 1. Making closures hashable
 2. Adding a way to create a hash for any object (aka. identityHash) and make HashSet/Map able to use an external hash/equality strategy instead of using the objects' own hashCode and operator==.

I agree that making the Hash-containers able to take a strategy is a good idea.
I would like an identityHash function, but it's important that it doesn't affect performance on the VM if you don't use it, and not too much if you do use it.

I would prefer these two to just making closures Hashable, since it's a more general solution.

[DartBot]

This comment was originally written by @bgourlie

---

It seems this issue is making it difficult to implement a sane model for user-defined events.

[larsbak]

We should make closures hashable and provide an easy to understand equals behavior.
There are three forms of closures:

1. From static methods. Since closures from static methods are canonicalized, identity check can be used for equality. Hash code should be identity hash code.
2. From instance methods. These closures are in essence pairs (method, this). Here the hash code can be computed from identity hash codes for "method" and "this". For equality we simply check methods and receivers match.
3. From inner functions. Use identity hash for hash code and identity check for equality. Any refinement in this area is hard to specify since it will depend on what in the lexical scope is being captured by the closure.

This in turn will make it possible to solve the problem with removing event handlers in the DOM without language guarantees for canonicalizing closures from instance methods.

[DartBot]

This comment was originally written by dha...@google.com

---

To be clear about #­2: if I have a type that overrides the equality operator, with instances 'a' and 'b' where a == b, would 'a.someMethod' compare equal to 'b.someMethod'? I'm guessing no, but clarity is good.

[sethladd]

I believe that a recent language review meeting decided that all objects shall be hashable. If so, this might now be a language issue.

---

Set owner to @gbracha.
Removed Area-Library label.
Added Area-Language label.

[sethladd]

Added Duplicate label.
Marked as being merged into #3369.