* Map is unnecessary and inefficient in almost every case.
* Replaced by the new HashMap.
* Renamed Map to RBMap and Set to RBSet for cases that still make sense
(order matters) but use is discouraged.
There were very few cases where replacing by HashMap was undesired because
keeping the key order was intended.
I tried to keep those (as RBMap) as much as possible, but might have missed
some. Review appreciated!
Adds a new, cleaned up, HashMap implementation.
* Uses Robin Hood Hashing (https://en.wikipedia.org/wiki/Hash_table#Robin_Hood_hashing).
* Keeps elements in a double linked list for simpler, ordered, iteration.
* Allows keeping iterators for later use in removal (Unlike Map<>, it does not do much
for performance vs keeping the key, but helps replace old code).
* Uses a more modern C++ iterator API, deprecates the old one.
* Supports custom allocator (in case there is a wish to use a paged one).
This class aims to unify all the associative template usage and replace it by this one:
* Map<> (whereas key order does not matter, which is 99% of cases)
* HashMap<>
* OrderedHashMap<>
* OAHashMap<>
To guarantee polymorphism, a method signature must be compatible with
the parent. This checks if:
1. Return type is the same.
2. The subclass method takes at least the same amount of parameters.
3. The matching parameters have the same type.
4. If the subclass takes more parameters, all of the extra ones have a
default value.
5. If the superclass has default values, so must have the subclass.
There's a few test cases to ensure this holds up.
Since enums resolve to a dictionary at runtime, calling dictionary
methods on an enum type is a valid use case. This ensures this is true
by adding test cases. This also makes enum values be treated as ints
when used in operations.
This makes sure that assigning values to enum-typed variables are
consistent. Same enum is always valid, different enum is always
invalid (without casting) and assigning `int` creates a warning
if there is no casting.
There are new test cases to ensure this behavior doesn't break in
the future.
the check read the return type of the setter, which doesn't exist and
lead to a segmentation fault. Now we check the first function parameter.
Probably a bad copy/paste of the getter case
