Re: newproxy()

[Cosmin Apreutesei <cosmin.apreutesei@...>]

> And then in your code write:
>
>        db:transaction( function()
>                -- modify db inside the transaction
>        end )

This inversion-of-control style can become spaghetti code quickly.
Consider having database connections, transactions, statements and
fetch cursors that you have to finalize, not just transactions.
Transactions need a connection context, statements need a transaction,
and so on down to cursor level. Code that event-driven style :)

> Immediate GC depends on knowing when all of the references to an object go away and in general we can't know that. Reference counting could catch most of them but comes with a fairly hefty performance cost.

You can always get me here cuz I don't know much about the internals
:) <speculation> the list of variables having __immediate_gc hooks
could be built on each lexical scope for each metamethod attachment
(just like __mode) and checked out on scope exit. This list would most
usually be empty. The broad idea is not affecting the performance of
releasing objects that don't hook to the gc (most of them that
is).</speculation>

> Where one would want syntactic help is in setting up lexical bindings for the variables that will be destructed. Again this is something that might be easier with dynamically scoped environments:
>
>        using2{ f = io.open( filepath ) }( function()
>                -- do stuff with file f. assumes that files support a dispose method (or using closes rather than disposing)
>        end )
>

As the example shows, lexical binding without without ref. counting
only covers the cases when the lifetime of objects it's short and it's
tied to the program flow.