Re: newproxy()

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

> Having also found newproxy() useful for finalization of Lua objects, I
> wonder why this is such a show-stopper. We all know that __gc happens
> in its own sweet time. But for Lua objects, __gc is an opportunity to
> ensure that some resource is released, eventually.

I find __gc useful only for releasing small memory objects allocated
by external allocators. For many types of resources it's useless:
 - for some types of resources (db transactions, graphics objects) the
release has visible effects or consequences on program behavior so
deterministic release is part of the program logic, which btw is not
an argument for forcing me to be explicit about the release and bloat
my program with release_this() and release_that() when lexical scoping
already tells me when the resources should go.
 - since __gc is non-deterministic you're not allowed to break the
program in a __gc handler, which also brings the irritating
restriction on not allowing __gc hooks from Lua; for some resources
breaking on release is a required feature.

That being said, I can't find a reason for newproxy() in Lua 5.2, now
that __len is checked for tables (my only use for it). Even if I
wanted to use newproxy() for __gc, I can't convert my table-based OOP
implementation to userdata-based cuz of virtualization holes.

I think a deterministic __immediate_gc hook would solve these
problems. I also wish the `for` protocol had included an exit hook
that would be called no matter how you exit the iteration (break,
return, error).