5.2: equality for closures
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: 5.2: equality for closures
- From: Alexander Gladysh <agladysh@...>
- Date: 2011年6月29日 00:15:53 +0400
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.
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.