Re: Lua 5.2 extensions (was Re: [ANN] mergelua)

[steve donovan <steve.j.donovan@...>]

On Wed, Oct 19, 2011 at 1:52 PM, Mike Pall <mikelu-1110@mike.de> wrote:
> The troublesome part are not the line numbers -- this can be
> handled with the existing per-prototype line-number table (LuaJIT
> actually compresses this table internally). But you'd really want
> to allow multiple source filenames, too. That's where it gets
> somewhat expensive.

Ah, right in general we would not have a simple one-to-one file
translation. But a restricted form might still be useful enough to
implement.

> The other issue is that setmetatable() will get more expensive for
> _all_ tables.

Now that's a definite ouch!  Thanks for such a detailed response,
especially the point that some overheads no longer get lost in the
noise when no longer interpreting.  Then it does feel like an
impediment to allow __gc on tables.  (There's always the old
newproxy() trick available)

Personally, I've done enough C++ to wish for scope-based deterministic
finalization. But it should not slow down the general case.

steve d.