lua-users home
lua-l archive

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

On 28/06/2011 22.15, Alexander Gladysh wrote:

Hi, list!

I apologize if this was already discussed. If this is the case, please
point me to the right message.

I have a problem with this clause from the Manual, section 3.4.3 —
Relational Operators:


Closures with the same reference are always equal.
Closures with any detectable difference (different behavior,
different definition) are always different.


(I assume that this applies to the case then closure is used as table
key as well.)

In our code we heavily use this function:

local unique_object = function()
     -- Note that table is not acceptable, since its contents are not constant.
     return function() end
end

It returns globally unique constant object that then (usually) is used
as a table key (usually to avoid name clashes).

Note, as comment says, the object can not be table — tables can be
changed, and, with Lua dynamic type system, this *will* lead to weird
bugs, where unique_object() result is accidentally used instead of a
table.

In 5.2 this function will no longer work due to above quote. And I
will not even be able to use newproxy() instead — as I understand
newproxy() is no more.
I wonder if it would be generally useful to resuscitate newproxy (with a safer implementation - IIRC that's why Lua team removed it). 

It would be very useful for these two tasks:

1. unique immutable table keys (what you need).
2. lightweight optimized proxy for tables used as objects (in OOP sense). I use tables for this task now, but with a rewritten newproxy optimized for this, maybe the overhead of this idiom (in size and generated garbage) would decrease.
BTW, I have also wondered why (full) userdata creation is only possible from C API. Wouldn't it be possible to devise a safe way to define and manage userdata from Lua? It could be useful for lots of things (maybe a bit advanced, but no more than those of "goto"), without resorting to C, therefore pushing farther the boundary where Lua could be used instead of C (leaving C only for high performance tasks or very tight system integration/communication). 




Please do not suggest to generate a Lua code string and then load it
to get a function — it is not acceptable, way too slow.

I understand that the new equality rules for closures are here as
(probably useful) optimization. But they kill a very useful idiom.

Any suggestions on how to workaround this?

Alexander.





Cheers.
-- Lorenzo