lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

This works if you have full control over the code. If, however, you want to
run code that you don't necessarily trust, you may want to protect yourself
from that code. Lua functions can be kept inaccessible, but the contents of
a table are visible to all. Proxy-table based solutions suffer from the
problem that one needs to put the reference to the real table in the
metatable and protect the metatable so that other code can't get to it. But
once protected, your trusted code can't get to the metatable either.

I'm mulling over a longer list of proposals on how to achieve encapsulation
with minimal changes. The simplest is replacing pairs and/or next with a
functions that look for metatable entries. If one can prevent table
iteration, then one can use private, table-based keys. The downside is that
the code inside the barrier can't iterate the table either.

Or if we really believe that encapsulation doesn't matter, then protected
metatables and environments could go away.

As for Objective-C, if you don't export a class declaration then the only
exposure of the fields in a class is via some of the introspection APIs and
you can get around that by nesting it all in a C struct if one is truly
paranoid. (Yes, code can touch pieces of an object by casting pointers, but
that's an issue with all C code.)


on 1/23/05 11:38 AM, PA at wrote:

> On Jan 23, 2005, at 20:17, Mark Hamburg wrote:
>> I think I'd rather worry about how to make
>> encapsulation work well
> What about:
> "If you do not want to access something inside an object, just do not
> do it."
> -- Roberto Ierusalimschy, December 2003
> For instance, in Objective-C, everything is totally accessible to
> anyone. But... one accesses undocumented methods/ivars at their own
> risk. This seems to be quite reasonable :)
> Explicit "encapsulation" is not that useful in practice. It's more of a
> good practice than anything else (e.g. protecting the innocents from
> themselves).