Near-Reality:Lua

From Old School Near-Reality Wiki
Revision as of 18:32, 4 October 2022 by Jacmob (talk | contribs) (Created page with "{{External|rs|rsc}} '''Lua''' is a programming language that is integrated into ''{{SITENAME}}'' with Scribunto. Lua source code is run from Modules in their own namespace, and invoked with <code><nowiki>{{#invoke:Module|function}}</nowiki></code>; this should done with a wrapper template. For example, if we have a module named "foo", then we should have a template called "Template:Foo" consisting of <code><nowiki>{{#invoke:Foo|main}}</nowiki><...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Lua is a programming language that is integrated into Old School Near-Reality Wiki with Scribunto. Lua source code is run from Modules in their own namespace, and invoked with {{#invoke:Module|function}}; this should done with a wrapper template. For example, if we have a module named "foo", then we should have a template called "Template:Foo" consisting of {{#invoke:Foo|main}} to call the module, and use {{Foo}} to use the module on pages.

For certain complex templates, Lua runs many times more efficiently than standard wikitext. It can also perform operations not available otherwise in wikitext. Unlike JavaScript, it is available to all readers, and does not need to be enabled. It is also run during parsing, rather than after.

All templates that directly invoke modules should be marked with the {{Invokes}} template.

Helpful tips

In order to produce Lua code that is free from bugs and to do so efficiently there's a few habits you should adopt as they will save you a lot of headaches.

Use the debug console

The debug console lets you test code while you're working on it. This saves you a lot of time. It also lets you avoid saving unecessary revisions just to see if your code is working. Instead you'll only be saving known working code after you're done with adding a feature. Don't wait too long though, in case your power or internet goes out.

You can test expressions such as:

= 2+2

which will return

4

as you'd expect.

You can also call into any function that is visible from outside. If you defined this function as part of for instance table p which you're then returning to Scribunto, you can call into this function from the debug console:

local p = {}

function p.calculate(num)
    return num + 2
end

return p
= p.calculate(3)

or

mw.log( p.calculate(3) )

yields

5

If this function were instead returning a table you could inspect it like so:

local p = {}

function p.calculate2(num)
    return { num + 1, num + 2}
end

return p
mw.logObject( p.calculate2(3) )

Sometimes you might not be interested in the output and only want to check if a function works. In the above example you could have used one of the following for that:

= #p.calculate2(3)
= type(p.calculate2(3))

Of course calling any Lua function from the outside, expects the function to only take one argument, the frame object, which we can't provide in the debug console, so we have to work around that. This is usually done by providing two entry-point functions, one which takes the frame object, grabs the arguments from it an passes it on to the real function like so:

local p = {}

function p.calculate(frame)
    local args = frame:getParent().args

    return p._calculate(args)
end

function p._calculate(args)
    local num = args[1]

    return num + 2
end

return p

Normal invocation of the module will use the p.calculate() function, but now you can debug the output from the real p._calculate() function in the debug console like so:

= p._calculate({3})

Validate all input parameters

Make sure to check all the input parameters you get from the entry point function, and do so early on. Invalid or unexpected data will cause your program to crash or misbehave.

Don't repeat yourself (DRY)

If your code has sections that look very similar there's a good chance it can be simplified. Always look for opportunities like this.

Keep it simple stupid (KISS)

Don't make something complicated if it doesn't need to be. Simpler code is easier to maintain. For instance maybe if you re-organized your data, it becomes much easier to handle in your code. Also do the task at hand really need a Lua module? If the problem is simple enough maybe a template or a macro will work just as well.

Avoid deep nesting

If you have too many levels of indented code, that's a sign you need to break out some code and put it into functions.

Comments

Good commenting is basically describing what a chunk of code does, not how it works. Also do not comment every line, you should comment every function and every major block of code.

See also