Re: Userdata environment

["Alex Davies" <alex.mania@...>]

Simply to save memory. A pointer to a table takes some 4 bytes (x86), where 
as a fully tagged value takes 12-16 bytes depending on alignment. When you 
consider that many people use userdata just to store 8-16 bytes, that's 
quite an optimization. Also by ensuring that the environment is never null, 
a minor time/complexity saving can be made there. (as getenv always returns 
a table).

The other way around your problem is of course to use a single weak keyed 
table, and your userdata as keys. It'd save a fair amount of memory, but I'm 
not sure which is better from a gc perspective.

- Alex

----- Original Message ----- 
From: "Shmuel Zeigerman"
To: "Lua list"
Sent: Monday, March 31, 2008 10:07 PM
Subject: Userdata environment


> Is there some reason behind enforcing userdata environment to be a table?
>
> I'd like to associate some userdata B with already existing non-table 
> value A. To achieve that, I have to create a new table, put A in there, 
> and set that table as the environment for B. This new table seems totally 
> unnecessary and affects efficiency. (I'd like to be able to just set A as 
> the environment for B.)
>
> A related issue: it seems that when a new userdata is created, its 
> environment is set to the C-function environment. The Manual doesn't say 
> anything about that. Is that an undocumented feature that is likely to 
> change? Or am I overlooking something?
>
> --
> Shmuel