[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Documenting Lua gotchas for newbies.
- From: Javier Guerra Giraldez <javier@...>
- Date: Fri, 3 Dec 2010 08:44:50 -0500
On Fri, Dec 3, 2010 at 7:16 AM, Hisham <hisham.hm@gmail.com> wrote:
> [*] Of course, this is a minor problem compared to explaining the
> weird behavior of the # operator. I predict it will be changed to
> return the actual number of elements of a table sometime around Lua
> 7.0 (when the argument that not maintaining a counter saves precious
> memory and processing won't be as compelling)
this has been discussed at length, but i don't think most people
realize that it's not that easy.
imagine that every table keeps a 'proper' length field, and #t returns it:
t={1,2,3} => #t = 3
t[2] = nil => #t = 3
t[3] = nil => #t =.... ? should be 1, right?
hum... the core would have to scan backwards to skip 2 and set it to 1
now:
t = {1,2} => #t = 2
t[1000000] = 3 => #t = 1000000
t[500] = 4 => #t = 1000000
t[1000000] = nil => #t = ....? should be 500, right?
now it doesn't seem so cheap to just keep a counter and update _every_
time you set a member to nil.
think about it, array-like handling suddenly gets O(n) for some very
common operations, instead of the current O(1) for most with a single
O(log n) for a single, relatively low usage operation.
--
Javier