Re: Modules and lexical scope

[David Manura <dm.lua@...>]

On Mon, Jul 12, 2010 at 10:25 AM, Jim Jennings
<jennings.durham.nc+lua@gmail.com> wrote:
> Patrick Donnelly <batrick@batbytes.com> wrote:
>> Personally I feel scripts shouldn't be able to modify a module's table;
>
> It doesn't matter if a script modifies a module's table, as long as
> the script has access only to a copy of the module's table.  However,
> your suggestion is an equally valid approach.  A module loader could
> create a table for the module that would enforce this (without
> modifying Lua).  Sure, there would be performance implications, but
> that's a different topic.
>
> My module system, Darwin [1], imposes no time performance penalties
> and only a small space penalty: some heap space is taken up by copies
> of _G and other modules' binding tables.  It's not a lot of extra
> space, and it could be eliminated if I had used read-only tables.  I
> did not use read-only tables for two reasons:  (1) They impose a time
> performance penalty because they must be implemented using an __index
> function, and (2) some existing Lua code won't run that way, and I
> designed Darwin to wrap existing Lua (and native) code, no matter how
> it was written.

The performance problems might be solved via a table that is lazily
copied on use.  Therefore, only fields that are used are copied, the
__index overhead is avoided on subsequent accesses, and writes--though
not prevented at run-time at least--do not harm the original table.
As a starting point,

  function make_copy(t)
    return setmetatable({}, {__index=function(clone,k) local v=t[k];
clone[k]=v; return v end})
  end

Incompatibilities with existing code may remain though.  OTOH, regular
copying might in some cases also cause incompatibilities: It's not
possible to copy all aspects of an object, such as its identity, i.e.
address, or some transient structure.