Protected tables proposal

[Mark Hamburg <mhamburg@...>]

I wrote recently about issues with proxy tables. They almost work, but are
awkward with respect to table iteration, table.insert, etc.. Here is my
thinking about an alternative.

1. Introduce a new mode flag "p" for "protected" or "proxy".

2. Introduce a function isprotected( t ) which returns true if t has this
bit set or is a full userdata.

3. Protected tables always go through __newindex and __index just like
userdata.

4. Move the current set of functions in table into rawtable. This should
also gain entries for pairs and ipairs matching the current definitions.

5. All of the standard table modification and access functions shift to
checking the isprotected status and if so calling through an appropriate
metamethod.

6. It would probably be useful to allow a value of true for the metamethod
to mean "do the default thing". This is mostly useful for __index and
__newindex.

7. Introduce new syntactic sugar '@var' and '@var = value' meaning:

    rawget( self, "var" ) and  rawset( self, "var", value )

The purpose of the last point is to make it lightweight to implement objects
as protected tables. I haven't checked whether the compiler can optimize for
this case, but I'm assuming that like with OP_SELF it would be possible to
have an opcode for @var access.

I purposely limited it to being sugar for self in order to avoid encouraging
people writing t@k as an optimization.

Not having actually changed the interpreter and tried coding with this there
may be some issues such as:

* Does protecting reads have too big a performance impact since all reads
would need to be checked? If so, I could easily see a case for not
protecting reads. It may, however, be possible that as long as we are only
protecting tables with metatables it becomes a small enough portion of the
operations not to matter.

* Does this impact the ease with which one can write methods? Should method
lookup perhaps bypass protection? Or are most protected tables likely to
have their methods accessed via __index anyway?

Mark