[jzoch]

yeah this is where traits instead of hierarchies become useful - I should be able to implement the Hash interface for an object I do not own and then use that object + trait going forward for HashMap and HashSet.

Java doesnt make this very composable

[nusaru]

Should be noted that Rust (one of the most prominent languages with traits) doesn't allow you to implement a trait for an object you do not own. A common workaround is to wrap that object in your own tuple struct and then implement the trait for that struct.

[Sharlin]

(If you don’t own the trait either, that is. Your own traits can be implemented for foreign types.)

Rust’s approach to the Hash and Eq problem is to make them opt-in but provide a derive attribute that autoimplements them with minimal boilerplate for most types.

Also, Rust’s Hash::hash implementations don’t actually hash anything themselves, they just pass the relevant parts of the object to a Hasher passed as a parameter. This way types aren’t stuck with just a single hash implementation, and normal programmers don’t need to worry about primes and modular arithmetic.

[mike_hearn]

Java uses this pattern in some places, for example you can usually pass a custom Comparator to anything that needs comparisons (like sorts).

Fully separating implementation of an interface from the data can create quite a lot of additional complexities. See my comment elsewhere about encapsulation and version stability.

[Phelinofist]

That sounds like a use case for the decorator pattern?