Re: [ Userdata ] __index aware of original lookup value

[Karel Tuma <kat@...>]

Excerpts from ThePhD's message of 2016-02-27 07:23:09 +0100:
Hi,

> Dear Miss Tuma,
Mr :)

> 
>      This looks like exactly what I wish vanilla lua would do[1].
> Unfortunately, I don't have control over the lua distro (I'm making a
> general purpose library that works across lua versions and with luajit for
> users other than myself). I would hope that one day, this becomes part of
> core Lua (I would make the petition, but I'm new here and I honestly have
> no idea who controls such a thing/who I need to talk to).
> 
>      I would imagine the best way to add it would be for lua to essentially
> provide a function `(lua_)lookup_value` (name pending a better bikeshed
> than in the deep of night) that pushes the lookup value on the stack /
> returns the value that originally failed lookup. Adding a third argument
> might disturb older code who perform switch statements based on the arity
> (int argcount = lua_gettop(L)) that lua provides the metamethod.

I'm pretty sure this popped up already on the list, and the answer was
"if you want funky inheritance, use __index getters all the way down"

This is not the only rough corner where you have to do stuff by hand
in lua.

Maybe in Lua 5.4?

You correctly identified problem with my solution - the third argument
could break existing code which does not expect the value in there (ie
the __index handler is shared with something else which passes the third
field for different purpose). I'm sticking with third arg because it's
the simplest implementation. Code which depends on stack top like you
mentioned is broken anyway :)

A more systematic approach could indeed be magic value stored in function
activation context, and accessed through some debug.* interface for the
lifetime of handler execution. However that needs more machinery:
special casing inside GC, plus one more field in the context, the
magic field accessor function. And we're not talking about LuaJIT yet
where introducing special purpose fields touches half a dozen places.

Finally, one might be tempted to do the same thing for __newindex, but
turns out that's almost never needed in OO implementations, because all
writes end up in the instance, there is no lookup chain.

> 
> [1] That looks like a super interesting project, though! Have you also
> considered things like implementing a new garbage collector for `ljx` too,
> since the one the original lua (and luajit) have implemented is essentially
> one of the earlier and older models?

Still hoping Mike will do it, as it's mentioned on his todo list.

My primary focus is more like secondary goals which have no chance of
happening in LuaJIT (such as rag tag 5.2 compat, this "third wheel"
to __index or completely unnecesary optimizations in odd places as my
needs arise).