View source for Module talk:Params

== New function <code>self</code> ==
I have added a new function to the module, &#123;&#123;[[Module:params|#invoke:params]]|[[Module:params#self|self]]&#125;&#125;, however I am not sure whether the most idiomatic name for it is <code>self</code> or <code>title</code> (especially considering that <code>self</code> has a special meaning in Lua). --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 00:36, 27 September 2023 (UTC)

:@[[User:Grufo|Grufo]]: I would prefer a different naming. Based upon magic words like {{tlm|PAGENAME}} and friends, things along the lines of <code>PARENTNAME</code>, <code>TEMPLATENAME</code> (sadly we already have a {{tl|TEMPLATENAME}} with a slightly different meaning), <code>INVOKERNAME</code> or similar come to mind, along with the possibilites of things like <code>CHILDNAME</code>, <code>MODULENAME</code>, <code>INVOKEENAME</code> or similar; potentially with modifiers for other encodings ''a la'' {{tlm|PAGENAMEE}} and [[mw:Manual:PAGENAMEE encoding#Encodings compared|comparison of page title encodings]], etc. (e.g., by returning [[mw:Extension:Scribunto/Lua reference manual#Title objects|mw.title:partialUrl()]] or similar), not to mention other options in line with things like {{tlm|FULLPAGENAME}}, {{tlm|FULLPAGENAMEE}}, etc. That said, perhaps those names are not really the best either and it would be better to stick to naming closer to Scribunto naming along the lines of <code>parentPageTitle</code>/<code>modulePageTitle</code> and stick to modifiers provided by <code>mw.title</code> object and/or <code>mw.url</code> API like <code>partialUrl</code>, <code>queryEncode</code>, <code>pathEncode</code>, <code>wikiEncode</code>, <code>anchorEncode</code>. Incidentally, I have often considered developing a Scribunto replacement for base (or even all the extensions in the default and/or WMF MediWiki packaging) magic words and then potentially extending it from there. This begs the need for these types of things more generally but I digress. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 19:51, 6 March 2024 (UTC)
:: @[[User:Uzume|Uzume]] Sorry for my very late reply. Your suggestions would be <syntaxhighlight lang="wikitext" inline>{{#invoke:params|INVOKERNAME}}</syntaxhighlight>, or <syntaxhighlight lang="wikitext" inline>{{#invoke:params|CHILDNAME}}</syntaxhighlight>, or <syntaxhighlight lang="wikitext" inline>{{#invoke:params|MODULENAME}}</syntaxhighlight>, or <syntaxhighlight lang="wikitext" inline>{{#invoke:params|INVOKEENAME}}</syntaxhighlight>. These would break the convention used for function names in this module, and also would not be so immediate to understand (i.e. if template <syntaxhighlight lang="wikitext" inline>{{foobar}}</syntaxhighlight> ''invokes'' this module I would expect “INVOKENAME” and the other names you propose to return <code>Module:Params</code> instead of <code>foobar</code>). There is a convention used by many programming languages according to which the parameter zero is the name of the routine executing the code (e.g. in [[Bash]] <code>$<nowiki />1</code>, <code>$<nowiki />2</code>, <code>$<nowiki />3</code>, … are the parameters, whereas <code>$<nowiki />0</code> is the name of the script or the name of the subroutine, much like our <syntaxhighlight lang="wikitext" inline>{{#invoke:params|self}}</syntaxhighlight>). However in these languages parameters can only be non-zero positive numbers, whereas in template syntax <code>0</code> can also be a parameter name (e.g. <syntaxhighlight lang="wikitext" inline>{{foobar|0=hello|1=world}}</syntaxhighlight>), so another solution needs to be found. There used to be an <code>arguments.callee</code> property in JavaScript with a similar meaning, but [https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/arguments/callee today is deprecated], and if we named our function <syntaxhighlight lang="wikitext" inline>{{#invoke:params|CALLEENAME}}</syntaxhighlight> I believe it would create confusion in redirected templates. The name “self” is what for me comes the closest to “parameter zero” in those languages that use the latter for the same purpose. And so “self” inside <syntaxhighlight lang="wikitext" inline>{{foobar}}</syntaxhighlight> is <code>foobar</code>. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 19:20, 22 May 2024 (UTC)
:::@[[User:Grufo|Grufo]]: To me <code>self</code> tends to lend its meaning from Lua in much the same way as as <code>this</code> does in C++, namely an [[object (computer science)|object]] reference (although in C++ these are always [[class-based programming|class-based]] and in Lua they do not have to be as they could be [[prototype-based programming|prototype-based]], etc.). It is true that in MW "title" has several meanings but its most common meaning is a textual name of a {{em|page}}, that said I would try to avoid it based on things like [[mw:Manual:Modeling pages|Manual:Modeling pages]]. That said page "title" and <code>PAGENAME</code> tend to be the name of a page without a namespace, as opposed to <syntaxhighlight lang=lua inline>frame:getTitle()</syntaxhighlight> and <code>FULLPAGENAME</code>, etc. You asked how people felt about the naming of the current <code>self</code> invocation target and though I am not a fan of "self", I do think it is better than anything with "title" in its name. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 10:16, 23 May 2024 (UTC)
:::: It's true I asked, but my concern was not about how understandable the term is, but about the fact that “self” has a peculiar meaning in Lua. And although this still holds true, it is also true that this module is not meant to be called by other modules (i.e. it is not meant to be used in Lua), but it is meant to be called by templates, where “self” has no special meaning whatsoever (plus, template writers are required to know nothing at all about Lua, and maybe one day modules will be written in more languages other than Lua). And ''even if'' a template writer knows about Lua, <code>self</code> would still make sense (i.e.  the “Lua-style ''self'' from the point of view of a template is the template itself”). If you mention words that are already in use, they would carry the reference they currently have (e.g. “title” would refer to the transcluding page, not the transcluded template), so we do need to invent new words that carry no references, since no magic word or template currently offers the same functionality. For me the only possible contender would be <code>callee</code> (but see what I wrote earlier about the case of redirected templates). --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 10:42, 23 May 2024 (UTC)
:::::Be verbose to avoid any confusion, it costs you nothing. How about calling_template_name? [[Special:Contributions/68.199.122.141|68.199.122.141]] ([[User talk:68.199.122.141|talk]]) 11:20, 23 May 2024 (UTC)
:::::: But that would be very confusing! This function is meant to be used in transcluded templates (otherwise one uses<syntaxhighlight lang="wikitext" inline>{{FULLPAGENAME}}</syntaxhighlight>); and if template <syntaxhighlight lang="wikitext" inline>{{foo}}</syntaxhighlight> calls <syntaxhighlight lang="wikitext" inline>{{bar}}</syntaxhighlight>, and the latter contains <syntaxhighlight lang="wikitext" inline>{{#invoke:params|self}}</syntaxhighlight>, we get <code>bar</code>, which is the ''called'' template, not the ''calling'' template (which instead would be <code>foo</code> – of course, technically the called template is also ''invoking'' a module, but users need to know nothing about Lua and modules for using <syntaxhighlight lang="wikitext" inline>{{#invoke:params}}</syntaxhighlight>). It is not a coincidence that in JavaScript the same functionality was called <code>arguments.'''callee'''</code> (and not <code>arguments.'''caller'''</code> – but again, “callee”/“called” create confusion in redirected templates). --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 13:08, 23 May 2024 (UTC)
:::::::In your example, template {{tl|bar}} is calling {{mlx|params|self}}, so {{tl|bar}} is the calling template (of your function), and its name is calling_template_name. It could be this_template_name as well. The word 'self' is usually used for the very object (with methods and stuff), not only its name. [[Special:Contributions/68.199.122.141|68.199.122.141]] ([[User talk:68.199.122.141|talk]]) 13:39, 23 May 2024 (UTC)
:::::::: <code>this_template_name</code> would also be possible. Let's see if others prefer it to <code>self</code>. Contra: although the funcion is meant to be used in templates, nothing forbids to use it in non-transcluded pages, wehere there is no such thing as “this template”; or imagine the page <code>Template:Foobar/doc</code> using <code>this_template_name</code> for referring to itself instead of the actual template it is documenting (i.e. <code>Template:Foobar</code> – that would also create confusion with {{tl|TEMPLATENAME}}). --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 21:09, 23 May 2024 (UTC)
:::::::::this_function_caller, I don't think it can be more precise; self, though, is a bit confusing when a page transcludes a template invoking a template invoking the function, or any such mumbo jumbo. [[Special:Contributions/68.199.122.141|68.199.122.141]] ([[User talk:68.199.122.141|talk]]) 22:50, 23 May 2024 (UTC)

== Wrapper template with pass-thru params ==

I'm a template writer and have newly discovered this Module, and am still getting on board with it, but have not used it yet. I think it probably will handle some use cases I have, but I'm not quite sure. One case that is typical for me, is a wrapper template with "pass-thru params", that is, the case of a wrapper template A, that calls template B passing thru all or almost all of A's params to B without alteration, and one or two more params with hard-coded  values. For a concrete example, consider template {{tl|sfnlink}}. I want to create new wrapper template {{tl|sfnlinknb}}, that will have the identical params that sfnlink has, less param {{para|nb}}; the job of the wrapper, is to pass through all of its params to {{tl|sfnlink}}, and add {{para|nb|yes}} as well. The "pass-thru" part of this seems like the kind of thing I ought to be able to do with Module:Params, but I'm not quite sure. Maybe using <code>for_each</code>? Thanks, [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 00:09, 3 December 2023 (UTC)

:It looks like you have a working implementation using double transclusion and <code>for_each</code> in {{tl|sfnlinknb}} already, but if it's useful as an alternative approach, I just used <code>concat_and_call</code> to do the same thing in {{tl|autnum plain}}: [[Special:Diff/1188117126]]. [[User:DefaultFree|DefaultFree]] ([[User talk:DefaultFree|talk]]) 13:26, 3 December 2023 (UTC)
:: [[User:DefaultFree|DefaultFree]], thank you '''so''' much for this. Your solution is infinitely better, and I've rewritten my wrapper using your idea. I had made multiple attempts—you can see the numerous failures at the history of [[User:Mathglot/sandbox/Templates/params_for_each]] and at [[Template:Sfnlinknb]]. At one point, I thought I had it because it worked perfectly at [[Special:ExpandTemplates]], but then I found it didn't work anywhere else—it spit out the correct code (as if it were nowiki'ed), but didn't invoke it, except at ExpandTemplates, for some reason. Then I went off on a tangent, trying to add {{tl|Eval}} in front of the whole thing to get it to execute, and as you saw, I got tangled up in double transclusion, and, oh, what a mess! Yours is so much better, and would make a great addition to the documentation of this Module, either as an example, or as a "Pro tip" note.  (You might be interested to see what I did with the (on-page) /doc, the {{no redirect|Template:Sfnlinknb/sandbox|/sandbox}}, and the [[Template:Sfnlinknb/testcases|/testcases]] pages for {{tl|Sfnlinknb}}.)  Thanks again, and I owe you one! [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 22:29, 3 December 2023 (UTC)

== 15th January 2024: New changes ==
The [[Module:Params/ChangeLog]] subpage now keeps the record of the most important changes in the module's code. Furthermore four new modifiers – <code>[[Module:Params#mapping_values_by_calling|mapping_values_by_calling]]</code>, <code>[[Module:Params#mapping_values_by_invoking|mapping_values_by_invoking]]</code>, <code>[[Module:Params#mapping_values_blindly_by_calling|mapping_values_blindly_by_calling]]</code> and <code>[[Module:Params#mapping_values_blindly_by_invoking|mapping_values_blindly_by_invoking]]</code> – were recently added to the module. These allow to pass each argument one by one to a custom template or a custom module in order to be preprocessed before further actions. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 04:07, 15 January 2024 (UTC)

== growth and sandboxes ==

Hi {{ping|Grufo}} - following on from your request over at [[WP:PERM]]. Got a few questions:
#Do you know what has recently caused the large growth in calls to this module? Is such a large use necessary?
#This module doesn't appear to have a /sandbox; now that it is so heavily used where are changes being validated prior to deployment?
Thanks, — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 13:34, 22 April 2024 (UTC)
:{{u|xaosflux}}, the drastic usage increase looks to be due to [[Special:Diff/1214727698]]. [[User:Primefac|Primefac]] ([[User talk:Primefac|talk]]) 13:42, 22 April 2024 (UTC)
::Numbers should start falling, I've undone the above. [[User:Primefac|Primefac]] ([[User talk:Primefac|talk]]) 13:50, 22 April 2024 (UTC)
:::FYI to {{ping|Uzume}} — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 14:19, 22 April 2024 (UTC)
::::@[[User:Xaosflux|Xaosflux]]: Thanks for the heads-up. I just fixed a minor documentation bug. Using something like this module insulated it from potential moves (or someone copying it for as a template, etc.) but there are obviously other ways to fix that issue and I certainly did not mean for it to have such ramifications (I would not want to prevent the author from development; the sandbox still allows such if somewhat more cumbersome). —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 14:31, 22 April 2024 (UTC)
: Hi [[User:Xaosflux|Xaosflux]]. I have no idea. I tried to find out, but I believe that whoever is responsible for the growth did not follow the suggestion of adding {{Tl|Lua}} to the documentation of the templates that start using this module. So finding out where all the calls come from is hard (btw, someone has to improve the “What links here” special page and allow to list direct transclusions only…). I had planned some important improvements for this module, but I have been very busy in the last months. And as soon as I had a bit of time for the module I found out that I can no longer edit it. Concerning the sandbox: it's not hard to create one, is it? So far every time I posted an update I tested it locally on my machine, but I agree that it would be good to have a sandbox here too. '''EDIT.''' [[User:Primefac|Primefac]] gave the answer while I was writing mine (@[[User:Primefac|Primefac]]: Thank you). --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 13:48, 22 April 2024 (UTC)
::Always happy to help. For the record, I used an insource search to find where it was being invoked, specifically <code>insource:/invoke:params/</code>, as seen [https://en.wikipedia.org/w/index.php?title=Special:Search&limit=500&offset=0&ns0=1&ns1=1&ns2=1&ns3=1&ns4=1&ns5=1&ns6=1&ns7=1&ns8=1&ns9=1&ns10=1&ns11=1&ns12=1&ns13=1&ns14=1&ns15=1&ns100=1&ns101=1&ns118=1&ns119=1&ns710=1&ns711=1&ns828=1&ns829=1&search=insource%3A%2Finvoke%3Aparams%2F here]. [[User:Primefac|Primefac]] ([[User talk:Primefac|talk]]) 14:19, 22 April 2024 (UTC)
::I've lowered the protection level on this, you should be able to edit again. Suggest you build up a sandbox and incorporate it to the testcases. — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 14:21, 22 April 2024 (UTC)
::: Thank you both @[[User:Primefac|Primefac]] and @[[User:Xaosflux|Xaosflux]]! The next changes in the code will pass through a sandbox. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 14:30, 22 April 2024 (UTC)

== Ready for general use ==
Improvements are always possible, but I believe [[Special:Diff/1224926156/1225161147|time has come]] to mark this module as [[:Category:Modules for general use|ready for general use]]. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 18:52, 22 May 2024 (UTC)

== Inverting parameters ==

At {{tlf|[[WP:RSPUSES]]}}, I needed not <code>|1=key|2=value</code> but <code>|1=value|2=key</code>. I achieved this with <code><nowiki>{{#invoke:params|sequential|mapping_by_calling|duses|values_and_names|setting|i|<br>|list_values}}</nowiki></code> when <code>call_for_each</code> didn't work. Are there plans to add a shortcut like <code>call_for_each_value_and_key</code>? [[Special:Contributions/174.92.25.207|174.92.25.207]] ([[User talk:174.92.25.207|talk]]) 21:56, 4 July 2024 (UTC)
: You followed exactly the right way. There are no plans to create a <code>call_for_each_value_and_key</code> function, because that will mean that we will have to create also an <code>invoke_for_each_value_and_key</code> function, a <code>magic_for_each_value_and_key</code> function, a <code>call_for_each_key</code> function, and so on. This module is already quite rich in functions; if new functions will be added in the future it will probably be to add new functionalities, not just syntax sugar. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 00:56, 6 July 2024 (UTC)

== Code link on mobile ==

{{re|Grufo}} Are you aware that the mobile view looks like this? <pre>
----------------------------------------
|               Function               |
| |----------------------------------| |
| |              count               | |
| |----------------------------------| |
|                  (                   |
|                code                  |
|                  )                   |
| Num. of arguments 0                  |
</pre> instead of the proper desktop view like this?
<pre>
              |-----|
     Function |count| (code)
              |-----|
--------------------------------
| Num. of    0                 |
| arguments                    |
</pre> Ideally the entire header should be on the same line like on desktop. But the parentheses in the code link are currently a monstrosity on mobile. [[Special:Contributions/174.92.25.207|174.92.25.207]] ([[User talk:174.92.25.207|talk]]) 06:03, 8 July 2024 (UTC)

: @[[User:174.92.25.207|174.92.25.207]]: Thank you. I think the quirk is too infobox-specific to be integrated in the {{[[Module:Params/doc/link to the code|./doc/link to the code]]}} template. However  [[Special:Diff/1233239047/1233369914|this]] should fix it. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 18:45, 8 July 2024 (UTC)

== Minor limitation currently affecting some functions ==
There is currently a design limitation in the [[:mw:Extension:Scribunto/Lua reference manual#frame:newChild|child frame]] object that affects <code>[[Module:Params#invoke_for_each|invoke_for_each]]</code>, <code>[[Module:Params#invoke_for_each_value|invoke_for_each_value]]</code>, <code>[[Module:Params#mapping_by_invoking|mapping_by_invoking]]</code> and <code>[[Module:Params#renaming_by_invoking|renaming_by_invoking]]</code>. The limitation affects these functions only when used on a large number of parameters (> 99). For more information see:
* {{Section link|Wikipedia talk:Lua/Archive 12|Editing the args metatable of a child frame}}
* [[:mw:Topic:Y61qv62t0k0w2b7f|Topic on Extension talk:Scribunto/Flow § Design problem in the frame object]]
--[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 20:03, 14 April 2025 (UTC)