Re: userdata environment

[Mark Hamburg <mark@...>]

The garbage collector may also expect that the environment is a table  
rather than an arbitrary object. That would be the other place to  
check when making changes.

Benchmarks are of course the "right" thing to do. The problem is  
figuring out what to measure that will be meaningful in a general  
context. if you need to create lots of userdata with an associated  
string, for example, then the intermediate table represents more  
memory, more steps on access, and more material for the GC to trace.  
That's all bad. On the other hand, there may be other parts of the  
system that benefit from the simplification of having environments  
always be tables and if you only occasionally need the non-table case,  
those cases might win out. So meaningful benchmarks need to know how  
to hit both sides of the case and how to compare them. Sorry, I can't  
offer any guidance there.

Personally, on Lightroom, I wished for the ability to store nil in the  
userdata environment table. For proxies for Objective-C objects,  
Lightroom uses the userdata environment to store links to other Lua  
values. That works well, but it takes special work to make sure the  
proxy stays alive even if the only references to the underlying value  
are to the native Objective-C object. We only want to do that special  
work when necessary and hence it would be convenient to have an easy  
way to tell whether or not a proxy has a custom environment. As it is,  
I forget whether I ended up assigning a special default environment  
and testing for equality or whether I encoded some flags into the  
proxy value. Neither solution was as attractive as simply storing nil  
in the environment.

Mark