It was just a simple example. To make an associate array emulation useful, must keep the list of keys sorted and use a binary search. Otherwise searching for keys sequentially could be intolerable even on the multi-core large-screen big-RAM computers of today that cost a few thousand dollars each one.
Could use the binary search in order to register the key and its related value, in case the key doesn't exist already in the array.
"Overlapping" keys might be the requirement for unique representation, which means case sensitive, which might not sit well with some people who are willing to use as much as a whole sentence as key rather than being forced to tell "KEY" from "key" and "KeY". Use the binary search for a request to enter a value. If the key (sanitized by LCASE$() or UCASE$()) exists then it's up to the user to replace the associated value, or try again with another key.
Another possibility, which is more difficult to program, is hash table. This is employed by the QB64 source code, for example. That case would make it impossible to go through the whole associate array expecting to get a listing of sorted keys or values.
Could use the binary search in order to register the key and its related value, in case the key doesn't exist already in the array.
"Overlapping" keys might be the requirement for unique representation, which means case sensitive, which might not sit well with some people who are willing to use as much as a whole sentence as key rather than being forced to tell "KEY" from "key" and "KeY". Use the binary search for a request to enter a value. If the key (sanitized by LCASE$() or UCASE$()) exists then it's up to the user to replace the associated value, or try again with another key.
Another possibility, which is more difficult to program, is hash table. This is employed by the QB64 source code, for example. That case would make it impossible to go through the whole associate array expecting to get a listing of sorted keys or values.