I wasn't thinking about C/C++, haven't touched those in years.
But that pattern, of a set that is keyed on an immutable function of the content rather than the whole content is prevalent. At least I've written a lot of code like that, but yet had the 💡 to abstract.
Had to validate myself with a quick implementation, which (like java's HashSet), is just a veneer over a HashMap.
But it makes me feel extremely stupid for not realizing I could write it before, instead of happily plastering put(e.getId(), e) all over the code base.
If we assume the objects are immutable, then I don't imagine it being really ugly, unless I'm missing something.
Similar to the `key` argument in most Python sorting methods, or Java's Comparator.comparing() - for type T, define T→U that returns the key, pass it to the set constructor.
You can't use the existing interfaces because those expect the order imposed by implementations to be consistent with equals (that is, equal keys iff equal objects, which may not be true here).
But I don't see where there'd be much complexity in a new implementation. What am I missing?
At Oxide we've found that key changes have always been a bug, but we could probably provide a method to reinsert a RefMut. I'm hesitant to do automatic reindexing, though, it feels too magical to me.
My mental model of the API is that of a set, not map.
As such, for the user, it doesn't materialize as reindexing, as long as the property that at no point you have two objects that map to the same key holds.
Comments
But that pattern, of a set that is keyed on an immutable function of the content rather than the whole content is prevalent. At least I've written a lot of code like that, but yet had the 💡 to abstract.
But it makes me feel extremely stupid for not realizing I could write it before, instead of happily plastering put(e.getId(), e) all over the code base.
Similar to the `key` argument in most Python sorting methods, or Java's Comparator.comparing() - for type T, define T→U that returns the key, pass it to the set constructor.
But I don't see where there'd be much complexity in a new implementation. What am I missing?
As such, for the user, it doesn't materialize as reindexing, as long as the property that at no point you have two objects that map to the same key holds.