Re: [Feature Request?] __key

[Dirk Laurie <dirk.laurie@...>]

2016-07-14 22:57 GMT+02:00 Sean Conner <sean@conman.org>:

> It was thus said that the Great Soni L. once stated:
>>
>> On 14/07/16 02:09 PM, Dirk Laurie wrote:
>> >I'm not usually shy to participate but I have not been able to understand
>> >what __key is supposed to do that lua_setuservalue and its exposure
>> >in the  debug library can't. Could you explain that from scratch?
>> >
>> To put it simply, it lets you use bigints as table keys as if they were
>> plain lua ints or floats.
>
>   Oh, so to clarify (kind of making the bigint library up):
>
>         bi = require "bigint"
>
>         x = bi.make(2^128) -- syntax issues but I want something
>         y = bi.make(2^128) -- really really large
>
>         t = {}
>         t[x] = "booya!"
>         print(t[y])
>         booya!
>
>   As it stands now, Lua will treat x and y as distinct values whereas Soni
> doesn't consider them distinct values (because they're distinct uservalues).

Thanks. A great light dawns on me.

The manual says:

   The indexing of tables follows the definition of raw equality in the
   language. The expressions a[i] and a[j] denote the same table
   element if and only if i and j are raw equal (that is, equal without
   metamethods).

The suggestion is that a exception to this rule should be made in
the case where i amd j are both userdata with the same metatable
which has a __key metamethod. Then, a[i] and a[j] should denote
the same table element if and only if _key(a) and __key(b).

If I has already said anything that I say below, please take credit
for the idea. I'm not going to re-read 20 messages carefully because
I now understand the question for the first time.

1. What is so special about userdata?

Why not tables? We don't have Python-like immutable tuples,
but one sorely misses them in for example a mutidimensional
situation. In Lua, a[{1,2,3}] = "@123" is fully legal, but a[{1,2,3}]
does not find it.

2. Why must the table implementation pay the bill?

It seems easy do it with __index and __newindex and a partial
proxy table for objects that have proxy keys. Then only the tables
that need it are slowed down.