Re: 5.2: equality for closures

[Alexander Gladysh <agladysh@...>]

On Wed, Jun 29, 2011 at 00:26, Peter Cawley <lua@corsix.org> wrote:
> On Tue, Jun 28, 2011 at 9:22 PM, Peter Cawley <lua@corsix.org> wrote:
>> On Tue, Jun 28, 2011 at 9:15 PM, Alexander Gladysh <agladysh@gmail.com> wrote:
>>> 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.
>>
>> And a table given the metatable of {__newindex = error, __metatable =
>> false}, thus making it immutable, isn't acceptable?

I would add __index = error as well.

But it will still pass the type checks as a table. Also, in stock Lua,
table creation is (as far as I can remember) significantly slower than
closure creation. (Yes, sometimes I create a lot of these objects.)

So, that's acceptable, but far from perfect.

> Or if you really want to use a function, rely on the fact that
> debug.upvalueid gives a detectable difference to things with different
> upvalues, allowing you to do the following:
>
> local unique_object = function()
>  local function f() return f end
>  return f
> end

This seems to be undocumented behavior. Thus it will break when/if
Mike will port LJ2 for 5.2.

Or am I wrong? Can one say that manual wording guarantees that this
will always work in "conforming" implementation?

Alexander.