Re: [Feature Request?] __key

[Coda Highland <chighland@...>]

On Thu, Jul 14, 2016 at 6:33 PM, Soni L. <fakedme@gmail.com> wrote:
>
>
> On 14/07/16 10:26 PM, Coda Highland wrote:
>>
>> On Thu, Jul 14, 2016 at 6:19 PM, Sergey Rozhenko <sergroj@gmail.com>
>> wrote:
>>>
>>> On Пт 15.07.16 2:57, Sean Conner wrote:
>>>>
>>>>     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!
>>>
>>>
>>> In this case __key would help at all. With or without it you'd have to
>>> keep
>>> a cache of these values, because it's needed to make __key return the
>>> same
>>> object. So, it's easier to make bi.make return the same object for both
>>> calls instead.
>>
>> That's not true at all. bi.__key could return a Lua "number"-type
>> value when the value is representable without loss of precision or a
>> string otherwise. This would provide for the nice property of
>> "t[bi.make(100)] == t[100]" in addition to the "t[x] == t[y]" desired
>> in the example.
>>
>> /s/ Adam
>>
> It probably shouldn't return a string, otherwise it becomes too javascripty.

It's just an example. You could use any other scheme you wanted as
long as Lua would consider it equivalent. A string is just
particularly convenient because it can store arbitrary data (so it
could contain a bitwise representation instead of a human-readable
one) and already works as a table key.

/s/ Adam