I have been using containers as map key and this seems to have worked very well so far. That is until we encountered an issue in the testing of new functions.
The “map.exists(container)” statement returned true for a container that was definitely not in the map yet. The container was similar, but did have some elements that were different. Yes, I am quite sure of this.
Is there any known issue that anybody might be aware of with using containers as map keys, or could I dismiss this as an anomaly due to some CIL compiling that might not have been up to date in the test instance?
I don’t see any issue with the containers. If there was an issue, they would not have been allowed using them as key in the map.
Did you try to debug and see for that kind of values, you are finding an issue.
CIL: Does your code runs in IL? Did you ever had a FULL CIL before and Incremental IL after your changes?
I imagine you may have figured this out or already opted for a different approach. However, others having the same issue may come across this thread. So I will explain a likely scenario:
Not sure if this applies to your case but this behavior is typical if the map is not declared with key type of Container. If you declare it like this “Map myMap = new Map(Types::String, Types::???)” then you are still allowed to insert containers as a key, without error. When you then lookup a key of a container type again, it may find elements that do not exists since the String key can not store the container supplied correctly. So, make sure the map is declared of correct and consistent Type, and used accordingly throughout if this behavior occurs.
When we run into such a topic, I’m always surprised that AX doesn’t come with any rules about what objects can be used as keys, how they should be implemented to provide good performance and so on. Especially if you compare it with how much effort was made in other environments (such as in .NET).
Regarding wrong types, AX should have a better runtime type control, but I also really miss generic collections (therefore it would be detected already during compilation).
Best of course if the map insert methods checked types on inserting. Compiler can not follow this error as the map can be initialised in so many places and reinitiliased etc … however, for a more secure developing, one might declare the types used in the map explicitly. Then when inserting values would create and error. ex:
Container myMapKey, myMapValue;
myMap = new Map(Types::container, Types::container);
then always populate the key and value variable and only insert them into the map
error will then occur if one mistakes the types … such as " myMapKey = dataArea.id;"