David Green wrote:
> Jon Lang wrote:
>> Bear in mind that keys are not necessarily sortable, let alone autosorted.
>> For instance, consider a hash that stores values keyed by complex numbers:
>> since there's no way to determine .before or .after when comparing two
>> complex numbers, there's no way to sort them - which necessarily means that
>> the order of :v is arbitrary, making %h[0] arbitrary as well.
>
> Aha -- I guess you're thinking in terms of "autosorting" that can be turned
> on to return the values ordered by < and >.
Not the values; the keys.
> But .iterator can do whatever
> it wants, which in the default case is presumably to walk a hash-table
> (technically not an arbitrary order, although it might as well be as far as
> a normal user is concerned).
...which is my point. When I speak of "arbitrary order", I mean that
the programmer should not be expected to know in what order the keys
will be returned. As opposed to a "meaningful order", whereas the
programmer can look at a set of the current keys and figure out which
index corresponds with which key.
>> This is why I was suggesting that it be limited to autosorted hashes: it's
>> analogous to how @a{'x'} is only accessible if you've actually defined
>> "keys" (technically, user-defined indices) for @a.
>
> Do you see that as a psychological aid? That is, if the order is arbitrary,
> %h[0] makes sense technically, but may be misleading to a programmer who
> reads too much into it, and starts thinking that the order is meaningful.
Something like that. Really, it's more about asking that the order
_be_ meaningful before you start using array-style indices, since
doing the latter carries the presumption of the former.
> My feeling is that it's fine for all hashes to support []-indexing. But if
> the order isn't important, then you probably wouldn't need to use [] in the
> first place (you'd use "for %h:v", etc.)... so maybe it should be limited.
> Hm.
That's my thought. That said, I'm wiling to consider the prospect
that such a restriction is excessive and/or unnecessary.
> P.S. Everywhere I said < and > I really meant .before and .after. =P
:) OK.
--
Jonathan "Dataweaver" Lang
