Page 3 of 4
Re: The Shared Namespace and You
Posted: Wed Feb 10, 2010 7:50 pm
by juraj
So if you were to use this convention, then that would mean that whatever name you used, would be a table, and each key in the table would be each of your variables and functions? Is there any slowdown caused by Mudlet having to look things up in a table every time that you run a bit of code?
Re: The Shared Namespace and You
Posted: Wed Feb 10, 2010 8:18 pm
by Jules
You don't necessarily need to put everything in a table, but the customnamespace.variable syntax can be useful.
For example, all of the Mantis code starts with "mantis", such as "mantisBalance, mantisEquilibrium", et cetera. The namespace is just a convention so other people's code that you port in won't screw with what you have already.
Re: The Shared Namespace and You
Posted: Wed Feb 10, 2010 8:48 pm
by Vadi
juraj wrote:So if you were to use this convention, then that would mean that whatever name you used, would be a table, and each key in the table would be each of your variables and functions? Is there any slowdown caused by Mudlet having to look things up in a table every time that you run a bit of code?
No, because you should localize the things you'll be using if you'll be using them often.
Ie in a script instead of doing:
result1 = math.max(1,2)
result2 = math.max(3,5,3)
result3 = math.max(5,3,1)
Where it has to lookup the max function in the math table 3 times, you should do:
local max = math.max
result1 = max(1,2)
result2 = max(3,5,3)
result3 = max(5,3,1)
So you only do one lookup, and 3 register accesses, which are way faster.
http://lua-users.org/wiki/OptimisingUsingLocalVariables
Re: The Shared Namespace and You
Posted: Mon Apr 18, 2011 8:44 am
by Widjet
Late to the conversation, but just a couple of points:
- I use a table, wjt, everywhere, and my goal is to have nothing in my profile outside of that table. The only exceptions at the moment are event handlers that have to be in the global namespace. I still wish the API allowed for registering arbitrary functions as event handlers.
- If I did have a name-space collision (someone else used wjt), I could do something like this:
Load order:
Script1
BobsScript
Script2
Script1:
my_wjt = wjt
wjt = nil
Script2:
bobs_wjt = wjt
wjt = my_wjt
my_wjt = nil
Since scripts are executed in a defined order, this would work perfectly.
- Finally, it is fairly easy to hack in a module-like system - you take a local snapshot of the Globals table before and after your module code, and move any changes into a table of your chosen name. I also wrote a nifty little function that imports all of the entries of a table into the local context:
function wjt.unpackLocal(tbl)
if type(tbl) ~= "table" then return end
local a = getfenv(2)
for k, v in pairs(tbl) do
a[k] = v
end
end
function test(tbl)
wjt.unpackLocal(tbl)
echo(a + b)
end
test({a = 1, b = 2})
echo(a)
-- echoes 3 and then nil.
Re: The Shared Namespace and You
Posted: Mon Apr 18, 2011 1:00 pm
by Vadi
That is rather neat.
Re: The Shared Namespace and You
Posted: Fri Jul 15, 2011 7:37 pm
by charysis
I just wanted to address two things:
#1:
counter = require("tobiascounting")
print(counter:tick() + counter:tick()) -- prints 3
Lua was designed SPECIFICALLY to support this type of 'module adoption'. As the original poster said, this leaves the user free to use whatever naming conventions he pleases/don't conflict with what he already has in place.
#2. You said (Heiko) that the problem with using modules is the setting of a working environment within that module preventing access to globals and such (which I don't think is a bad thing). I can think of a few simple workarounds - explicitly pulling things needed from the global table via assingment, or an __index metamethod to the global table as a couple examples. In fact, a gate wouldn't be a bad idea: then you could track changes to the global table from within your module, ensuring you don't accidentally overwrite a value there or restricting access to variables your module shouldn't be seeing anyway.
I'm not trying to be argumentative - but I'm curious why you are opposed to such?
The Lua developers are pretty clever, I have seen great use of the module function in other projects and I don't see why it wouldn't work here.
Re: The Shared Namespace and You
Posted: Fri Jul 15, 2011 7:45 pm
by charysis
I just saw Widjet's post:
Finally, it is fairly easy to hack in a module-like system - you take a local snapshot of the Globals table before and after your module code, and move any changes into a table of your chosen name.
That is kind of what I was describing but that seems more expensive than the functions already built-in to Lua.
I'm with what's-person's-name on this one: with proper use of modules and inheritance, we could be distributing modules that
don't even have names and allow people to give them one as they require it. Or better yet, a simple script to track modules that are loaded and simply give a module a free index as it is required.
module(..., package.seeall)
Re: The Shared Namespace and You
Posted: Fri Jul 15, 2011 7:54 pm
by Vadi
Do note that module() was removed in the upcoming Lua 5.2.
Re: The Shared Namespace and You
Posted: Fri Jul 15, 2011 8:07 pm
by charysis
Holy heck!! *digs through changelog frantically*
Hey, does this mean your dropping LuaJIT2? 5.2 has a library for bitwise operations
Edit: oh, I already knew about this.. you said module(), not 'modules' in general. Yeah, so the syntax I gave is deprecated but .. the point more or less stands.. ?
Re: The Shared Namespace and You
Posted: Fri Jul 15, 2011 8:09 pm
by Vadi
Er... no, of course not. LuaJIT2 is just more than it's bitwise library, and that isn't even it's main feature.