On 2003-01-29 at 09:44:27, Aaron Sherman wrote: > Yes, I would expect that. In my opinion there is no difference between > an array and a hash other than the underlying storage and the > type-management of the key. Perhaps it is your opinion that those should be the only differences, but the actual differences, at least in existing languages, are a matter of fact. :) Every language I know of which supports both types distinguishes between them - even those which use the same subscripting syntax for both. So the distinctions must be important.
1. Ordering. The elements of an array have a defined order. The elements of a hash do not. 2. Contents. Arrays are a collection of values. Hashes are a collection of key/value associations. The indices in an array are just a by-product of the above fact that the values are ordered; there is no intrinsic association between, say, the number 1 and the second element. A consequence is that, even when the underlying implementation allows them to be sparse, arrays conceptually do not have any missing elements. If you create a brand new array by giving it a 5,000th item, then the first 4,999 items are logically there even if they're not taking up any memory. (What their value should be is the subject of the parallel thread on array defaults). For example: People keep bringing up JavaScript, so let's look at that language. It is true that JavaScript arrays are implemented on top of hashes. Every object in JavaScript, including an array, is an associative array/hash. But Arrays are a special class because they have the concept of a length. You can give any object properties associated with numeric keys, but only Arrays have their length field automatically updated; furthermore, this is magic that cannot be duplicated by user code: a = new Array a[2] = 'baz' a.length => 3 o = new Object o[2] = 'baz' o.length => undefined > I'm increasingly of the opinion that a) > there should be no @ vs %, there should be no {} vs [], there should be > a keys, values, defined, delete, exists, push, pop, shift, unshift for > every container and foreach shouldn't give a damn. Okay, let's look at adding hash operators to arrays first. 1. keys. Easy enough - return 0..a.length 2. values. Easy, if redundant. a.values is identical to a itself. 3. defined. Sure. Any value in Perl may be defined or not, no matter what sort of container it's in. 4. delete. No reason you can't remove an element from an array, but it's effectively a splice - the later elements move down. 5. exists. exists(a[i]) ::== 0 <= i < a.length Now let's look at array operators on hashes. 1. push. As long as the argument is a Pair, I guess this makes sense. h.push( k => v ) ::= h{k} = v 2. pop. Problem: no ordering. There is no "last" value. which one should this remove? 3. shift. ditto. 4. unshift. identical to push. My point boils down to this: the semantics are fundamentally different no matter how similar or different the syntax is. -- Mark REED | CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754