[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Lua 5.2, setfenv and the C API
- From: steve donovan <steve.j.donovan@...>
- Date: Mon, 11 Jan 2010 11:27:06 +0200
On Mon, Jan 11, 2010 at 2:13 AM, Alexander Gladysh <agladysh@gmail.com> wrote:
>> This decision seems to indicate a philosophy of encapsulation by default, while still allowing users and embeddors to choose to expose or bridge information into other environments to the degree they wish and no more.
>
> Well, yes, but isn't the existance such module would be a "hack
> against the Lua 5.2 language"? Almost the same as if one would create
> a module which would allow people to bypass the __metatable
> protection.
I think Nevin has it here. There is nothing that hack-like about
exposing Lua internal APIs, providing it is understood that such
extensions are necessarily more implementation-dependent (and Lua
internals change rather slowly.) You're the boss, and you can extemd
Lua to suit your purposes while still remaining universal through the
module mechanism, that's the beauty of the language. For example, it's
easy to expose lua_createtable, and this can be very useful to someone
wishing to populate big arrays efficiently:
http://batbytes.com/luafaq/#T4.4
(It isn't a public API, because the array/hash distinction is
ultimately an implementation detail)
A module can do stupid/unwise things, sure. We assume that people are
grown-ups and are conscious of what they are making available. You
would simply not allow these things in a sandboxed environment.
steve d.
- References:
- Lua 5.2, setfenv and the C API, Brett Nash
- Re: Lua 5.2, setfenv and the C API, Alexander Gladysh
- Re: Lua 5.2, setfenv and the C API, Leo Razoumov
- Re: Lua 5.2, setfenv and the C API, Alexander Gladysh
- Re: Lua 5.2, setfenv and the C API, Nevin Flanagan
- Re: Lua 5.2, setfenv and the C API, Alexander Gladysh