Wiktionary talk:Scribunto/Converting templates

"you must then store [require's return value] in a variable to use it later"

Alternatively, we can have modules add themselves to global variables. For example, if we used en_wikt as a sort of "holder" for these things, we could have Module:foo-bar-baz could register itself as en_wikt.foo_bar_baz, rather than requiring callers to store the module as a local variable. This is what the built-in modules do: require('mw.ustring') creates mw.ustring, so you don't need to actually use its return value. (In fact, we don't even need to use a "holder" — the module could just add itself as foo_bar_baz if we wanted — but I think it's better to organize things hierarchially so we don't pollute the namespace too much.)

If we take that approach, I think we'll want to be consistent about it, to avoid confusion; I mean, if a certain module isn't intended to be used from other modules, then that's fine, but all modules that are intended to be used from other modules should add themselves to the same global "holder" (if we use one). So I won't edit this page to mention that approach unless we agree that we want to do this and how we want to do it.

—Ruakh_TALK 22:47, 19 February 2013 (UTC)

I think the main disadvantage is that it creates a discrepancy between modules that are meant to invoked and modules that are only for Lua-internal use. Invoking a function requires that it return its contents the "old fashioned" way, so such a module would have to do both (return and add global). However, they don't have to export the same set of functions through both methods. The advantage of that is that there is no point in exporting a function Lua-internally if it takes a "frame" object, since that means that it's meant to be invoked from a page. So, the set of returned functions (which all take a frame object) could actually be "wrappers" around the same functions that end up in the global table (which take other parameters). That would make it quite useful, but it's also rather complicated and I'm not sure if we can expect all coders to understand this idea. —CodeCat 00:52, 20 February 2013 (UTC)

Re: first sentence: It doesn't have to. We could just use this approach for all modules.   Re: last several sentences: I dunno there's any desire to separate "back-end" functions that would only be called from Lua (potentially including other modules) from "front-end" functions that would only be called directly from templates, then I would think that the best way to effect that separation should be effected by simply having two separate modules, rather than by having a single module export itself in two separate ways. (But I wouldn't expect it to be very useful to separate things in this way, anyway.) —Ruakh_TALK 09:02, 20 February 2013 (UTC)

But we can't use it for all modules, that was what I meant. For a module to be callable from a template, it has to return a table of functions. Of course it could also return a table as a global variable. But, regardless, the set of functions that a module returns is the set of functions that can be called from templates. So we can't avoid having to return functions at least some of the time. This means that as far as consistency is concerned, we can either decide to always return functions regardless of their intended usage, or always export functions as globals if they are intended for Lua-internal use, and export functions by returning them if they are intended to be called from a template. Considering the fact that the set of template-callable functions will generally be entirely separate from the set of Lua-callable functions (because it would usually not be desirable to make a new "frame" object or pass one around everywhere), I think the second option makes more sense. Of course, not all modules will need to export functions in both ways at the same time, but when they do, we can follow this idea. —CodeCat 15:27, 20 February 2013 (UTC)

Sorry, I think we're talking at cross-purposes. I was taking for granted that a module will always return (i.e., be) a table of functions; I was simply suggesting that modules could also add this table (i.e., themselves) to a global variable. —Ruakh_TALK 15:37, 21 February 2013 (UTC)

Even if the functions are meant to be called internally? —CodeCat 16:48, 21 February 2013 (UTC)

Functions that are truly internal — called neither by templates nor by other modules — can just be local functions. (See w:Encapsulation (object-oriented programming).) But if a function is going to be called by external code, be it template code or other-module code, then it might as well be exposed in a straightforward way for both cases. —Ruakh_TALK 03:04, 22 February 2013 (UTC)

I'm striking this discussion, since it was based on a false premise: as far as I can tell by testing, modules' modifications to global variables are not visible to other modules that import them (that is: "globals" are not actually shared between different modules), so we actually can't do this. —Ruakh_TALK 03:59, 1 March 2013 (UTC)

Some thoughts

An advantage that Scribunto has over curly-bracket templates is that a module can vet its parameters and generate error messages. e.g you can say "local stem = args[1] or error("1st parameter (stem of adjective) missing!")" and the like. I used this in the new versions of {{it-noun}} and {{it-adj}} and found about a dozen entries that had mistakes in their template calls (bad genders, wrong number of parameters etc).

Secondly, as a programmer from the age of steam, can I make a request that you add comments to your code. Especially if you code something "clever" that another person may not understand, or you may yourself forget after a few months.

Thirdly (and I probably don't need to say this), if you find yourself coding the same piece of logic multiple times in the same module - implement it as an internal function (it is very easy in Lua). SemperBlotto (talk) 17:01, 21 February 2013 (UTC)

Seconded: well commented code - plus lots of whitespace. I have looked at templates written by myself and had a problem sorting out what they do! — Saltmarsh^{απάντηση} 06:50, 15 May 2013 (UTC)

mw.title

Does mw.title actually work? Can someone (CodeCat?) point to an example of a working module that successfully uses it? I couldn't get it to work, so I concluded that it wasn't deployed here yet, but CodeCat's recent edits make me think that maybe I'm just missing something. —Ruakh_TALK 06:40, 6 March 2013 (UTC)