[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Problems with proxies
- From: Mark Hamburg <mhamburg@...>
- Date: Thu, 16 Sep 2004 09:55:35 -0700
Lua's use of proxies works quite well but runs into a variety of problems
when trying to do things like create observed tables that report changes to
external systems. The problems include:
* pairs and ipairs don't work on the proxy table
* table.insert, table.remove, table.concat, table.sort, table.getn,
table.foreach, and table.foreachi all fail to work properly on the proxy
Furthermore, unless one uses a userdata proxy, none of these routines will
signal errors since they are being handed a table. If one does use a
userdata proxy, then you run into the complexities associated with userdata
holding references to Lua data.
I can see a variety of "solutions":
1. Add metamethods for all of these operations and have the default
implementations check for them. One would also need a "rawtable" namespace
to access the primitive operations.
2. Introduce the explicit notion of a proxy
3. Provide a better way for userdata to reference Lua data -- for space
reasons, one might need to do this as a new flavor of userdata -- and then
use this as a proxy
4. Provide a standard method table for tables so that one would be
encouraged to write t:insert( v ) rather than table.insert( t, v ). Proxy
objects could then re-implement the methods.
The messy part about the last one is that Lua's external semantics say that
method lookup is identical to table lookup. (It's internal implementation
would allow it to be different.) That would create problems if you were
building a set of words and one of the words happened to be "insert".
word = "insert"
t[ word ] = true
After this, t:insert ceases to work properly. This probably won't happen
often in practice since tables which one treats as arrays will be less
likely to have other keys defined, but it's still problematic and I can
envision cases such as building an ordered set of words in which one wants
to use both the array portion and the dictionary portion of a table.
There are probably a variety of other benefits that flow from allowing table
indexing and method calls to be distinguished -- including easier bug
catching -- but this is a separate thread from the discussion of what would
make proxies really do well at standing in for tables.