Re: [Feature Request?] __key

[Coda Highland <chighland@...>]

On Sun, Jul 17, 2016 at 6:47 PM, Tim Hill <drtimhill@gmail.com> wrote:
>
> On Jul 17, 2016, at 5:14 AM, Philipp Janda <siffiejoe@gmx.net> wrote:
>
> Am 17.07.2016 um 10:05 schröbte Sean Conner:
>
> It was thus said that the Great Tim Hill once stated:
>
>
> Where is the synthetic key value stored then? It must be stored in the
> key+value slot of the table. Where is the userdata stored? In the same
> place. So now we are storing three items per table slot, not two. Seems to
> me a significant impact.
>
>
> The synthetic key is stored as key in the table (or is implicit in the array
> part). The userdata is not stored at all (unless `__key()` returns it). The
> synthetic key is used _instead of_ the original userdata.
>
>
> Which is pretty horrible too…
>
> u = <some userdata with __key>
> t = {}
> t[u] = “foo” — Lua calls __key here
> t[u] = “bar" — Let’s hope __key returns same value every time!
> u = nil — Goodbye last reference to u!
>
> So now we have the potential for a userdata to splatter content all over a
> table by playing tricks with __key. Not good. And a userdata that vanishes
> even though we have (apparently) stored it as a table key. Not good. And if
> u doesnt return the same key every time, good luck finding the key in the
> table, short of enumerating the whole thing.

As I mentioned in my message: If a developer implements __key, they
are promising a certain contract. If your code sample here has any
surprising behavior, then the library developer has violated the
contract.

Yes, all bets are off at that point, but this isn't the only place
that could happen.

If I had to take a guess, you're zealously against operator overloading?

/s/ Adam