Re: [Feature Request?] __key

[Coda Highland <chighland@...>]

On Sat, Jul 16, 2016 at 10:52 PM, Tim Hill <drtimhill@gmail.com> wrote:
>
> If __key() for u returns something other than 10, really surprising things
> are going to happen.
>
>
> Like what?
>
>
> Like it deleting another totally unrelated key+value pair from the table,
> and if you don’t find that surprising then I don’t know what to say.

Obviously that could surprising, but it's the developer's
responsibility to make sure that things behave sanely, and it's
possible to make surprising things happen in any sufficiently
expressive language.

Keep in mind that table keys are immutable, and they don't trigger any
metamethods, even with the proposed __key extension. If you end up
with a table or a userdata as a table key, then reference identity is
the only thing that matters. The equivalency class of the table key
isn't going to change dynamically. Meanwhile, if you've got an object
(whether table or userdata) with a __key metamethod, then the only
time that metamethod gets called is when you try to dereference into
or assign into a table, and you would certainly hope that the object's
current value is the one that's going to be used as the table key.

That is to say, unless the library developer is doing something wrong,
you would expect that t[o] would always refer to the same table slot
as long as you haven't done anything to mutate o, and if you put o
back to the state it was in before (or construct a new object
representing the same value) then once again it's referring to the
same slot.

I mean... you expect THIS behavior:

t = {}
k = 1
t[k] = 1
k = 2
assert(t[1] == 1)
assert(t[k] == nil)

So why would THIS be any different?

t = {}
k = ud(1)
t[k] = 1
k.setTo(2)
assert(t[ud(1)] == 1)
assert(t[k] == nil)

/s/ Adam