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
