Declaring a class method called "hash" leads to an unhelpful error

[shopify]

Declaring a class method called "hash" leads to an unhelpful error

[paracycle]

Yes, very fair point - we have now changed the name!

Awesome. That's a smart move against some future WTFs in your codebase. 😂

You may choose not to do anything about this. Maybe this issue can just be a documentation / pointer to anyone who follows.

I would still like to fix this since Tapioca tries really hard to be resilient against all kinds of user manipulation of types. I mention some of the wild things libraries do that we had to protect against in my RubyKaigi talk.

PS: Nice touch with the XKCD link :)

[paracycle]

Oh, I see what is happening here, thanks for the detailed report. I'll see how we can fix this but, in the meanwhile, I would like to note that your method name choice is quite problematic.

Your FooTest class is overriding Object#hash in an incompatible way. Normally Object#hash is used to calculate a numeric hash key value which is used to figure out where to place the object in a Hash table. That is what makes Hash lookups efficient.

Your override is returning an Hash value from that method instead, so Ruby has difficulty using the class as a Hash key, and, in turn, as a Set value, since Sets are built using Hashes.

These would all fail:

> Set.new([Foo])
TypeError: no implicit conversion of Hash into Integer
> { Foo => "bar" }
TypeError: no implicit conversion of Hash into Integer
> h = {}; h[Foo] = "bar"
TypeError: no implicit conversion of Hash into Integer

You should keep that in mind if you ever want to use the class as a Hash key at some point.

[hlascelles]

Yes, very fair point - we have now changed the name!

You may choose not to do anything about this. Maybe this issue can just be a documentation / pointer to anyone who follows.