Re: hpairs?

[Drake Wilson <drake@...>]

Quoth GrayFace <sergroj@mail.ru>, on 2010-12-28 21:11:55 +0600:
>             until type(k) ~= "number" or k < 1 or k >= n or k % 1 ~= 0

I'm a little wary of that floating-point modulus

> It uses the fact that 'next' first traverses array part and then
> hash part. Massive, but should be fast for rehashed tables.

This sort of behavior will be banned, period, once my Evil Overlord
credentials have been suitably established.  Seriously:

  *****
  The order in which the indices are enumerated is not specified, even
  for numeric indices.
  *****

Don't 'use the fact' that a certain implementation happens to be put
together a certain way and start relying on it for correctness.  It's
hard enough avoiding doing that by accident.  Doing it on purpose is
worthy of the Sun Flinger.

My earlier version almost works except for the checking for integers
bug, because it relies on a well-defined interface boundary regarding
the set of integer keys iterated by ipairs.  I think I still like the
table solution better though; it's not just correct, but more clearly
correct, and it will tend to track ipairs even if the latter goes
through any incompatible changes later on (though I kind of doubt it
ever would).

But really I'd tend to just avoid having hpairs/ipairs in the first
place and if I'm going to make a bipartite table avoid storing any
values at numeric keys that don't fall into the array-esque part, then
filter on the 'number' type.  There's a couple of reasons I can
imagine for iterating all the non-ipairs keys, but most of them are
rather specialized and would have an ipairs right next to them anyway.

   ---> Drake Wilson