Re: keys in tables

[Gavin Wraith <gavin@...>]

<20051210150308.1252151e.eric@theeric.com>
In-Reply-To: <20051210150308.1252151e.eric@theeric.com>
X-Organization: Home
User-Agent: Messenger-Pro/1.00c (MsgServe/1.00a) (RISC-OS/5.10) POPstar/2.05
Reply-To: lua@bazar2.conectiva.com.br
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

In message <20051210150308.1252151e.eric@theeric.com> you wrote:


> Non-synthesizability is an important option to have. What this means is
> that if you see someone has a value at point B, you know that ultimately
> that value had to have come from point A. This means you can use
> reachability analysis to prove useful things about your program.
> 
> Some applications:
> 
> 1. Ancillary data. Sometimes you want to have several modules attach
> data to an object, and they don't necessarily know about each other. In
> other languages where you're restricted to a string key, if both modules
> say happen to choose "obj.foo", there would be a namespace collision.
> But democratic Lua actually gives you two ways to avoid this, both of
> which rely on using a table as key:
> 
> weakTable[obj] = value
> 
> or
> 
> local opaqueKey = {}
> obj[opaqueKey] = value
> 
> In either case, in order to access the attribute value, the user must
> explicitly have access to weakTable or opaqueKey respectively. They
> cannot accidentally synthesize an equivalent for those objects the
> way that can happen for value types.
> 
> 2. Security. With some customization to the Lua environment, you can
> expand on this concept to prevent intentional collisions as well as
> accidental ones. You'd have to make sure that the user couldn't peek
> into your table using pairs() (nor the debug interfaces,etc.), but once
> you did, you could know that the user wouldn't be able to get anything
> out of your table if they didn't possess one of your keys. There are a
> variety of useful security patterns, like sealer/unsealer:
> 
> function makeSealerUnsealer()
>     local s = {}
>     local u = {}
>     function s:seal(val)
>         return { [u]=val }
>     end
>     function u:unseal(seal)
>         return seal[self]
>     end
>     return s, u
> end
> 
> u:unseal(s:seal(x)) == x
> 
> which is analogous to public/private key encryption, but where we
> rely on the VM's support of closures' privacy rather than obscure
> numeric properties for security.
> 
> (I hope this makes a case for virtualizable __pairs, btw.)

Many thanks for this Eric. I found this very clear and educational.
It deserves a piece in the Lua Tutorial on the wiki.

-- 
Gavin Wraith (gavin@wra1th.plus.com)
Home page: http://www.wra1th.plus.com/