Re: [Feature Request?] __key

["Soni L." <fakedme@...>]

On 17/07/16 03:58 AM, Tim Hill wrote:
> > There are exactly two times when the __key metamethod gets called:
> >
> > t[ud] = v  --> t[ud.__key()] = v
> > v = t[ud]  --> v = t[ud.__key()]
> >
> > Of note, it does NOT get called in this situation:
> >
> > k = ud.__key()
> > assert(t[k] == v) -- no __key used here!
> >
> > But this absolutely ought to work.
> >
> > Yes, there's ONE extra check made when accessing a table ("does the
> > key have a __key metamethod, yes or no?") so yes it does TECHNICALLY
> > make things more expensive, but this isn't anywhere close to a "good
> > luck with performance" kind of impact.
> 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.

You say "it must" yet you never explain "why?". Given current float 
behaviour, I don't see why "it must" at all.
> And yes, a given __key *should* return the same value each time it is called for a given userdata in a given state. But if it doesn’t strange things happen. Strange in that they vastly complicate the table contract. And to what end?

__len already does that.
> I’m not being obtuse here, I just don’t see the bang for the buck.
>
> —Tim

--
Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.