lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

With regard to explicit scope management, I believe that Adobe went this direction in the Lightroom SDK.

An interesting point of comparison are autorelease pools in Cocoa. The short summary is that Cocoa maintains a per thread stack of pools of object in need of a release call. (This turns out to make reference counting a lot easier to work with since you can return a value with a pending reference count decrement.) When you create a new pool, it chains onto the existing pool (if any) for the current stack. When you destroy a pool, it releases any pools chained below it. Most code can get away with a single pool at the top level for processing a command. If you need more prompt clean up or you allocate a lot of objects in a loop, more localized pools are useful. The key point that makes them work well from an API standpoint, however, is that one finds the current pool by looking for a thread local variable rather than needing to pass it in everywhere.

Given coroutines, I'm not sure what the definition of thread local would be since really what we are looking for is call chain local, but conceivably we could provide a way to hide the scope managers from most of the code while still making their services available. (A general notion of call stack controlled dynamic variables would be interesting for all of the usual reasons why dynamic variables are interesting.)