lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


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