Re: [Feature Request?] __key

[Coda Highland <chighland@...>]

On Mon, Jul 11, 2016 at 4:29 PM, Soni L. <fakedme@gmail.com> wrote:
> On 11/07/16 07:57 PM, Coda Highland wrote:
>>
>> On Mon, Jul 11, 2016 at 3:54 PM, Soni L. <fakedme@gmail.com> wrote:
>>>
>>> After LuaConf 2016, more specifically the Lua stored procedures talk, I
>>> kept thinking about something... They had to modify the Lua VM just so they
>>> can decay userdata into keys when indexing, everything else could be done
>>> with a substitution layer on top of Lua. So, can we get a __key metamethod
>>> *for userdata only* that takes an userdatum and returns a value to be used
>>> for table indexing? For t[k] and t[k] = v this is pretty simple to
>>> understand, but Lua isn't that simple: - How should rawget() and rawset()
>>> work? - Should there be a way to invoke __index and __newindex without
>>> invoking __key? (rawkeyset() and rawkeyget()?) - Should there be a way to
>>> invoke __key without indexing? (getkey()?) (for use with rawset/rawget) - Or
>>> is this the wrong way to go about it?
>>
>> Just to verify: Are we effectively discussing something equivalent to
>> Python's __hash__? /s/ Adam
>
> No. Keys would still be compared with rawequal() and stuff. The only thing
> is that userdata with __key would use the value returned by __key as the
> key.
>
> E.g. if you have a "decimal" userdata (DBs have a "decimal" type),
> t[decimalObj] may decay to t[aPlainOldLuaNumber] if decimalObj is within
> some range, or to t[internedDecimalObj] (lazy interning) otherwise. With a
> "buffer" userdata, perhaps t[bufferObj] decays into t[aPlainOldLuaString].
> Note that in this last case a mutable type (buffer/userdata) decays into an
> immutable type (string).
>
> This is way better than __hash__; this is more like fusing __hash__ and
> __eq__ but only for userdata.

Sorry, my mistake: I meant __hash__ for the purposes of acting as
dictionary keys. I didn't mean LITERALLY functioning like it.

But your description satisfies me that the answer is, effectively, "yes."

/s/ Adam