lua-users home
lua-l archive

Re: [ANN] Lua 5.4.0 (work1) now available

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

It was thus said that the Great Egor Skriptunoff once stated:
> 
> *Remark #2*At second sight, this "undef" idea has big problems with
> compatibility.
> If I understood correctly, in Lua with NILINTABLES table keys
> with nil values will NOT be GC-ed.
> To release a key in a table, undef must be pseudo-assigned instead of nil.
> Unfortunately, this breaks most of old Lua code.
> Almost all Lua projects will need to change its internal logic
> to avoid memory leakage. (Memory leakage here is about having a lot of
> unneeded keys with nil values which are not available for GC)
> Yes, searching for literal nil assignment will find most of places
> we should change.
> But there would be a lot of hard-to-find places such as
> -- func may return nil sometimes
> t[k] = func(k)
> or
> -- intentionally skips nils and stores only non-nils
> table.insert(t, get_next_val())
> Rewriting old projects would be hard and error-prone.
> We all have a lot of old code we don't remember in details how it works.
> The price of rewriting Lua 5.3 code to Lua 5.4 will be too high.
 Hmm ... how about this? Make undef a special value that acts like a
storable nil? 
	x = { 1 , 2 , nil , 4 , 5 }
x is *NOT* a sequence---nil is still nil. But
	y = { 1 , 2 , undef , 4 , 5 }
y *IS* a sequence. It's just that y[3] has an undefined value. It can be
treated as nil, such that
	y[3] == nil -- this is true
This should avoid the problem with older Lua code that expects 
	foo.bar = nil
to have the key bar GCed. Also:
	function foo(...)
	 local x = table.pack(...)
	 dump("x",x)
	end
	foo(1,2,nil,4,5)
	x =
	{
	 [1] = 1,
	 [2] = 2,
	 [3] = undef,
	 [4] = 4,
	 [5] = 5
	}
 You get rid of the x.n hack as well.
 -spc

AltStyle によって変換されたページ (->オリジナル) /