Imagine a combined hash/array CONTAINER type. The difference between
hashes and arrays becomes that arrays are restricted to non-negative integer
key values. @grumpy and %grumpy can even have the same head node in their
data structure, but the accessors will, unless told otherwise, only pick out
the integers or the non-integers, by default, giving us familiar perl5 semantics.
Peter Haworth wrote:
> What's wrong with defining each() on arrays?
>
> while(my($i,$v)=each @array){
> print "Element at $i is $v\n";
> }
>
> Then if you have a sparse array, you only get the defined elements, otherwise
> you get all of them.
>
> Whether for iterates over the defined elements of a sparse array, or all of
> them is another question.
if all containers are trees, it means instead that we have to dummy up
keys for non-sparse arrays.
> If that gets optimized into an iterator, you're
> only likely to get the defined elements, because that'll probably use the
> same mechanism as each(). I suppose there could be two mechanisms, then
> implementors could choose whether to make them do the same or different
> things. Otherwise, there should be some way of specifying that you want all
> elements (or only defined, whatever the default isn't) when creating an
> iterator or using a for loop on an array.
> I suppose this also gives you the choice with each():
>
> while(my($i,$v)=each @$array){} # Default iterator
> while(my($i,$v)=each $array->iter_all){} # All elements
> while(my($i,$v)=each $array->iter_def){} # Defined elements
> This is looking like for/each should act on iterators "natively", and create
> an iterator if given a list/hash.
the various internal functions would be accessible through long names,
for the wizards, but in general an object would know what kind of
for or each function would be run on it, through polymorphism.
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
My argument is the result of selectively breeding straw men
