[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: _SELF and _SUPER
- From: Sean Conner <sean@...>
- Date: Fri, 5 Aug 2016 22:44:21 -0400
It was thus said that the Great Soni L. once stated:
>
> _SELF and _SUPER would make the compiler insert some things into the
> bytecode that don't get erased/don't count as "debug info".
>
> Using debug.* is literally relying on debug info. And order of
> locals/upvalues. And so on. None of that is guaranteed, while the
> proposal can use mechanisms not yet available and stuff.
>
> For example, this code:
>
> local x;
> print(_SELF["x"])
>
> Could produce a sequence of opcodes like:
>
> R(1) = nil -- e.g. LOADNIL
> R(2) = Upval[1][K(1)] -- e.g. GETTABUP
> R(3) = K(2)[K(3)] -- e.g. GETTABLEK / GETTABLE with a statically
> allocated table constant
> R(3) = R(R(3)) -- e.g. MOVEI / move from indirect register (because the
> I is on the right, and the RHS is the source)
> R(2)(R(3)) -- e.g. CALL
>
> where:
>
> K(1) = "print"
> K(2) = statically allocated table: {["x"] = 1}
> K(3) = "x"
>
> This would be for reading only. For writing, it'd use R(R(x)) = R(y)
> (e.g. IMOVE) instead. For calling, it'd retrieve the current function
> from the call stack or something. For passing it around, it'd copy all
> locals into a table, maybe set a __call metamethod as well.
To what end? What problem does this solve? What you one use this for?
-spc