lua-users home
lua-l archive

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

I think I've been having fun coming up with various import()'s if I do nix my constraint to not touch _ENV.  The latest is: table.import() :p

Oh well, fun to consider everything I suppose :]

table.import =
    function (self, t, ...)
        local pref, keys

        if select('#', ...) > 1 or (... ~= nil and type(...) == 'table') then
            keys, pref = ...
            pref, keys = ...

        keys = keys or {} 
        pref = pref or '' 

        -- table-empty check
        if not next(keys) then
            for k in pairs(t) do 
                table.insert(keys, k) 

        for _, k in pairs(keys) do 
            self[pref .. k] = t[k]

local new_env = {} 

table.import(new_env, string, { 'reverse', 'rep', 'sub' }, 's')
table.import(new_env, io, 'io_')
table.import(new_env, os)

_ENV = setmetatable(new_env, { __index = _ENV, __newindex = _ENV }) 

local f =
    function () 
        io_write('blah. ~\r\n')

print(sreverse('cat'), srep('donut', 5), ssub('abcdefg', 3, 6))


On Wed, Nov 20, 2013 at 1:24 AM, Tim Hill <> wrote:

On Nov 19, 2013, at 12:44 AM, Sir Pogsalot <> wrote:

 My mistake for making it seem like I was primarily arguing that locals are better for performance and this should be the biggest reason for having an import().  The main reason *is* brevity.  But if I say brevity I'm treated like I'm lazy, if I say efficiency I'm flooded with "well why not LuaJIT?", and no matter how many times I try to politely remind people I'm still reading suggestions involving _ENV.  I get it: For most cases touching _ENV works, but I do not agree that is is convenient or appropriate ALL the time.  I still get this overwhelming sense of "feature suggestion?  BURN THE WITCH" from this list. 

If your main reasons is brevity then I would agree some syntactic sugar does have some potential. I think, however, that you would still have to explicitly list every single item. That said, it would still make sense to do something like:

local from table.insert, table.delete, x, y.z.k

As sugar for:

local insert = table.insert
local delete = table.delete
local x = x
local k = y.z.k

This approach is pure sugar; as long as the list is explicit names then there is no conflict between compile-time and run-time knowledge, and you end up with cleaner code with almost no compiler overhead. The problems only arise if you try to impute the list from the run-time contents of tables.

As for burn the witch … One of the benefits of Lua is it’s adherence to “smaller is better”, which is good (imho). However, as with all such philosophies, there is always the danger of dogmatism. And yes, I think sometimes there is a little too much vociferous objection to suggestions here. This is a shame, as it tends to put off people making or supporting suggestions for new features, which in turn obscures which new features people actually do want. I admit I’ve pretty much given up on making suggestions here for that reason.