[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Function environment table interface
- From: Jerome Vuarand <jerome.vuarand@...>
- Date: Tue, 7 Jul 2009 11:49:58 +0200
2009/7/7 Rob Kendrick <firstname.lastname@example.org>:
> On Mon, 6 Jul 2009 21:30:43 +0100
> Peter Cawley <email@example.com> wrote:
>> > While I can't see how it makes any functional difference to how they
>> > are done, it does mean there is only one interface the programmer
>> > has to remember rather than one, as well as removing two functions
>> > that pollute the global namespace. It also feels more orthogonal
>> > and consistent.
>> > What am I missing?
>> Firstly, environment tables are per-function, whereas all functions
>> share a single metatable, so function environments could not be set
>> via metatable. Secondly, separating the environment from the metatable
>> allows for one to be per-instance and one to be per-class.
> I can't quite think of a reason why you'd want the environment to be
> per-instance, and not some of the other metatable fields, but OK.
For example your userdata1 may contain a pointer to another userdata2,
so to prevent userdata2 from being collected before userdata1 you may
want to keep a reference to userdata2 in some table associated with
userdata1. You can then use either the metatable or the environment of
userdata1 to store these per-instance references.
However, since some metamethods (eq, lt, le) only work if the
metatable is shared by several userdata (ie. per-class metatable), you
have to use the environment to hold per-instance data.