Re: pairs(t, skey) and ipairs(t, skey)
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Re: pairs(t, skey) and ipairs(t, skey)
- From: Tim Hill <drtimhill@...>
- Date: Sun, 6 Oct 2013 01:00:30 -0700
On Oct 6, 2013, at 12:03 AM, David Heiko Kolf <david@dkolf.de> wrote:
> Dirk Laurie wrote:
>> Cheap alternative: Fixed-length table. Length defined once for all. Larger
>> indices treated as non-numeric. This may actually cover quite a large
>> number of actual use cases
>
> This was the pre-5.1 way, where the length could be either stored in an
> 'n' field or in an internal table property.
>
> Out of curiosity, does anyone have links to discussions why the
> possibility of storing the length in a field of the table (as `t.n`)
> isn't used anymore? Why doesn't the default length operator check for
> `t.n` first before doing the binary search?
>
Well one big advantage is that # has a corresponding meta function, so it's easier to create abstractions than using the old "n" system.
@Dirk: "Larger indices treated as non-numeric?" What do you mean?
And in either case, you would still have O(n) performance hot, which Roberto apparently feels is unacceptable.
--Tim
- References:
- Re: pairs(t, skey) and ipairs(t, skey), Roberto Ierusalimschy
- Re: pairs(t, skey) and ipairs(t, skey), Leo Razoumov
- Re: pairs(t, skey) and ipairs(t, skey), Luiz Henrique de Figueiredo
- Re: pairs(t, skey) and ipairs(t, skey), Tim Hill
- Re: pairs(t, skey) and ipairs(t, skey), Luiz Henrique de Figueiredo
- RE: pairs(t, skey) and ipairs(t, skey), Schmidt, Phil
- Re: pairs(t, skey) and ipairs(t, skey), Javier Guerra Giraldez
- Re: pairs(t, skey) and ipairs(t, skey), Robert Virding
- Re: pairs(t, skey) and ipairs(t, skey), Dirk Laurie
- Re: pairs(t, skey) and ipairs(t, skey), David Heiko Kolf