Then, why did you emit that idea (in bold) if it's not because you know that's what people want
If you bolded the full phrase, I added: "if Khaled wanted". It certainly wouldn't be my choice of implementation, I'm just laying out all the options. I've made it clear quite a few times what I'd like to see, but of course I realize there are other opinions involved.
it would allow us to have an array-like way to store data is wrong for two main reasons: that's not the good way to do it
It's "wrong" because "that's not the good way to do it"? That's pretty vague-- care to elaborate? I don't see any idiomatic problems with storing array data in an associative structure-- it would be equivalent to storing an array of array pointer structures internally in C (minus the tiny overhead of the linked list hash structure that goes along with a hash impl). The point of -i would be to optimize the insertion/deletion by changing the hash function to simply be
h(n) = n, and, again optionally, ensuring that only 1 value can be associated with a key by shifting on
h(n+1) or
h(n-1).
Reusing the existing hash infrastructure would mean a more stable implementation that takes advantage of all of the existing features for hash tables, of which there are many. Some of which you might be discounting are $hfind, /hsave, and /hload, any of which risk being omitted from an initial array implementation-- all of which, would share many important use cases for array structures. This is the argument I am posing.
1) I want to see real array implemented with all the efficiency it implies
2) I want to see array implemented using hash table, with all the inefficiency it implies
These two options are not mutually exclusive, and are also loaded logical fallacies. The "inefficiency" that everyone is pointing to regarding hash tables is unfounded and based solely on mIRC's parsing capabilities, not the efficiency of hash structures themselves. In other words, the claim is misplaced. Also note that there is nothing inherently more efficient about arrays and hashes. Let's review some CS 101:
Hash table lookup: O(1). Array lookup: O(1).
We're even so far.
Hash table deletion: O(1). Array deletion: O(n).
Hashes are more efficient! This of course implies different behaviour, though-- to make it fair:
Hash table deletion with shifting: O(n). Array deletion: O(n).
Equal. Insertion is the same.
So, show me where arrays are significantly more efficient? The theory shows that you are wrong-- many existing efficient hash implementations would agree with the theory (to the point where our own basis of benchmarking, $ticks, would probably not be able to differentiate). And, especially since most of the overhead in hashes can be optimized out if you know your key values are integer indexes, it almost becomes moot.
