6 ms·
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 o
by jzoch 3y ago
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 3y agoShould 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 3y ago(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.
- Phelinofist 3y agoThat sounds like a use case for the decorator pattern?
- mike_hearn 3y agoJava 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.