Is there a reason we have to use HashMap::set() instead of the way cooler syntax:
hashMap ["key"] = "value";For compatibility with standard containers, I’m thinking to make HashMap::operator[] return a private Proxy object that supports assignment and conversion to ValueType. But why wasn’t this done in the first place?
Also, is a HashMap of ReferenceCountedObjectPtr supported? i.e. HashMap <String, ReferenceCountedObjectPtr > ?
Anyone???!
It’s just a really old class - if I was writing it now, I’d certainly have done it differently! Yes, using a proxy is probably the right way to handle it…
Okay, I thought you had some twisted genius reason for it. If you could just give me short overview on what you would do differently, I would love to hear it. Because I am going to do some work in it and I can incorporate your ideas.
Well, I’d need to spend a bit of time thinking about it, but my gut feeling is that returning a proxy object like you suggested would be the best way to do it. Or maybe it’d be better for operator to always add a new entry and return a reference to it? Not sure. Looking at the way std::hash_map and boost hash maps are done would probably be a good plan!
Okay. But what else would you change?
I don’t have any other thoughts on it right now! I’ve actually hardly ever used that class myself, TBH.
Well as you can probably imagine std::unordered_map and boost::unordered_map are heavily utilized classes in server applications!
Absolutely - and generally those are what I’ve used myself when I’ve needed a map. (Oddly, I don’t think I’ve really ever needed a map in the library itself though).
