[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: 'oldindex' metamethod?
- From: "John Hind" <john.hind@...>
- Date: Fri, 19 Sep 2014 17:17:58 +0100
Message: 4
Date: Thu, 18 Sep 2014 22:01:38 -0500
From: Javier Guerra Giraldez <javier@guerrag.com>
Subject: Re: 'oldindex' metamethod?
To: Lua mailing list <lua-l@lists.lua.org>
Message-ID:
<CAFkDaoRs1=jqZupU0zodvY4-3uT+wP1fQ8nEA6czi-N_Gti28w@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Thu, Sep 18, 2014 at 5:18 AM, John Hind <john.hind@zen.co.uk> wrote:
> Combining 'oldindex' with existing features ('len', 'newindex' and
> tracking
> variables) we could:
>
> - Constrain a table to be a proper vector/list (so length would always
> be valid).
> - Redefine length so it is a defined value for the previously
> undefined cases (0, -1 or nil for example).
> - Redefine length so it is a true count of all the elements in the
> table regardless of key.
> - Redefine length so it is the largest positive integer key regardless
> of 'holes'.
Javier Guerra Giraldez <javier@guerrag.com> wrote
>unfortunately, all these possibilities (except maybe the first one, i'm not
sure)
>result in a O(n) time profile for each value erasure.
> that's a cost most of us are not willing to pay just for more palatable
operators.
That is the point of 'oldindex' - using it in tandem with 'newindex' you can
count elements
in and out of the table storing the count somewhere (maybe in a hidden
field). No need to
look at any other elements, just the one being deleted and the stored count.
(Admittedly
some interpretations of the last case might involve some scanning back, if
you do not want
to permit holes at the top of the sequence - but that is a little esoteric).
Attachment:
smime.p7s
Description: S/MIME cryptographic signature