You're basing that on what exactly? That's insane. The inefficiency of using hash tables that way is ridiculous.
Immutable data structures are common. Would you be opposed to immutable arrays in mIRC? If you treat them as such, the structures themselves are fine. In any case, the "inefficiency" of using hash tables is not due to the hash tables themselves, but mIRC's god awful parsing slowness. That's not really an issue with using associative arrays. Adding extra syntaxes to get around flaws in the language isn't a good solution, it's just a workaround. There's nothing fundamentally wrong with using associative arrays themselves, so it's misleading to claim that the inefficiency is in the hash table-- it's not. There are things mIRC could do instead to optimize these slow points without adding in new syntaxes.
They're two fundamentally different concepts.
This is another pointless computer science theoretics discussion, and quite wrong. The fact is that "associative arrays" are a generalization of indexed arrays, conceptually speaking. An associative array is a collection of objects in a mapping of one key to a value, usually in a one to one relationship. An indexed array is just a subset of an associative array whereby the keys are all indexed positive integer values. This is why the two types of arrays map so seamlessly together in languages like PHP/JS. There is no fundamental difference, except for the key type restriction in indexed arrays. All of the operations on associative arrays carry over for indexed ones, the only difference being that insertion/deletion involve changing other keys. I don't consider that "fundamentally" different.
But that's all besides the point-- I'm not interested in the theory. The fact that you can trivially create an array API based on hget/hadd (and even hdel, though we agree it's inefficient) proves that the APIs have minor differences. Here it is, for immutable(ish) arrays:
; Add a value to an array
alias aadd { hadd -m $+(array,$1) $calc($hget($+(array,$1),0) + 1) $2- }
; Get a value from an array
alias aget { return $hget($+(array,$1),$2) }
; USAGE:
; //aadd myarray foo | aadd myarray bar
; //echo -a $aget(myarray,1) == foo
; //echo -a $aget(myarray,2) == bar
Seems like a rather trivial API difference to me. Again, insertion/deletion could be wrapped in a similarly trivial way, with the efficiency caveats, of course.
PHP's conflagration of lists and mappings into a single "array" is one of the major flaws in the language. And Javascript has (mostly) proper arrays.
This double standard doesn't actually make sense. Javascript and PHP share the exact same API and conceptual implementation of the "array". If PHP is "flawed" because of this decision, then so must Javascript be. In any case, this is a hugely subjective debate-- many would argue that it's one of PHP's most powerful features-- this same API is certainly one of JS's most powerful features. The efficiency might vary between the two implementations, but that is an implementation detail, not a conceptual one, and we're not here to discuss implementation details. How can assoc arrays be a flaw in one language but a "mostly ok" feature in another, conceptually? I think associative arrays make plenty of sense in a high level weakly typed scripting language like JS, PHP and even mIRC. Conceptually speaking, using hash tables as the associative arrays of the other languages makes perfect sense. I've used them in mIRC with little issue many times before.
Just FYI, mIRC could always optimize a hash table for insertion/deletion if a switch was supplied during creation. This is why I had previously suggested the -i switch in the thread you linked, to tell mIRC to optimize the keys as indexed integer values. Using such a switch, mIRC could collapse/shift indexes during insertion/deletion-- or even just store the internal structure as a pure array for super-duper-efficiency, if Khaled wanted. This would give you the power of associative arrays in one single interface that scripters are already used to, rather than splitting it up into an API to manipulate associative arrays with indexed integers and associative arrays for anything else. I think a unified interface would be easier.
