Module talk:Params

New function self

I have added a new function to the module, {{#invoke:params|self}}, however I am not sure whether the most idiomatic name for it is self or title (especially considering that self has a special meaning in Lua). --Grufo (talk) 00:36, 27 September 2023 (UTC)

@Grufo: I would prefer a different naming. Based upon magic words like {{PAGENAME}} and friends, things along the lines of PARENTNAME, TEMPLATENAME (sadly we already have a {{TEMPLATENAME}} with a slightly different meaning), INVOKERNAME or similar come to mind, along with the possibilites of things like CHILDNAME, MODULENAME, INVOKEENAME or similar; potentially with modifiers for other encodings a la {{PAGENAMEE}} and comparison of page title encodings, etc. (e.g., by returning mw.title:partialUrl() or similar), not to mention other options in line with things like {{FULLPAGENAME}}, {{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 parentPageTitle/modulePageTitle and stick to modifiers provided by mw.title object and/or mw.url API like partialUrl, queryEncode, pathEncode, wikiEncode, anchorEncode. 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. —Uzume (talk) 19:51, 6 March 2024 (UTC)

@Uzume Sorry for my very late reply. Your suggestions would be {{#invoke:params|INVOKERNAME}}, or {{#invoke:params|CHILDNAME}}, or {{#invoke:params|MODULENAME}}, or {{#invoke:params|INVOKEENAME}}. 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 {{foobar}} invokes this module I would expect “INVOKENAME” and the other names you propose to return Module:Params instead of foobar). 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 $1, $2, $3, … are the parameters, whereas $0 is the name of the script or the name of the subroutine, much like our {{#invoke:params|self}}). However in these languages parameters can only be non-zero positive numbers, whereas in template syntax 0 can also be a parameter name (e.g. {{foobar|0=hello|1=world}}), so another solution needs to be found. There used to be an arguments.callee property in JavaScript with a similar meaning, but today is deprecated, and if we named our function {{#invoke:params|CALLEENAME}} 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 {{foobar}} is foobar. --Grufo (talk) 19:20, 22 May 2024 (UTC)

@Grufo: To me self tends to lend its meaning from Lua in much the same way as as this does in C++, namely an object reference (although in C++ these are always class-based and in Lua they do not have to be as they could be prototype-based, etc.). It is true that in MW "title" has several meanings but its most common meaning is a textual name of a page, that said I would try to avoid it based on things like Manual:Modeling pages. That said page "title" and PAGENAME tend to be the name of a page without a namespace, as opposed to frame:getTitle() and FULLPAGENAME, etc. You asked how people felt about the naming of the current self invocation target and though I am not a fan of "self", I do think it is better than anything with "title" in its name. —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, self 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 callee (but see what I wrote earlier about the case of redirected templates). --Grufo (talk) 10:42, 23 May 2024 (UTC)

Be verbose to avoid any confusion, it costs you nothing. How about calling_template_name? 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{{FULLPAGENAME}}); and if template {{foo}} calls {{bar}}, and the latter contains {{#invoke:params|self}}, we get bar, which is the called template, not the calling template (which instead would be foo – of course, technically the called template is also invoking a module, but users need to know nothing about Lua and modules for using {{#invoke:params}}). It is not a coincidence that in JavaScript the same functionality was called arguments.callee (and not arguments.caller – but again, “callee”/“called” create confusion in redirected templates). --Grufo (talk) 13:08, 23 May 2024 (UTC)

In your example, template {{bar}} is calling {{#invoke:params|self}}, so {{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. 68.199.122.141 (talk) 13:39, 23 May 2024 (UTC)

this_template_name would also be possible. Let's see if others prefer it to self. 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 Template:Foobar/doc using this_template_name for referring to itself instead of the actual template it is documenting (i.e. Template:Foobar – that would also create confusion with {{TEMPLATENAME}}). --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. 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 {{sfnlink}}. I want to create new wrapper template {{sfnlinknb}}, that will have the identical params that sfnlink has, less param |nb=; the job of the wrapper, is to pass through all of its params to {{sfnlink}}, and add |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 for_each? Thanks, Mathglot (talk) 00:09, 3 December 2023 (UTC)

It looks like you have a working implementation using double transclusion and for_each in {{sfnlinknb}} already, but if it's useful as an alternative approach, I just used concat_and_call to do the same thing in {{autnum plain}}: Special:Diff/1188117126. DefaultFree (talk) 13:26, 3 December 2023 (UTC)

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 {{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 /sandbox, and the /testcases pages for {{Sfnlinknb}}.) Thanks again, and I owe you one! 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 – mapping_values_by_calling, mapping_values_by_invoking, mapping_values_blindly_by_calling and mapping_values_blindly_by_invoking – 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. --Grufo (talk) 04:07, 15 January 2024 (UTC)

growth and sandboxes

Hi @Grufo: - following on from your request over at WP:PERM. Got a few questions:

1. Do you know what has recently caused the large growth in calls to this module? Is such a large use necessary?
2. 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, — xaosflux ^Talk 13:34, 22 April 2024 (UTC)

xaosflux, the drastic usage increase looks to be due to Special:Diff/1214727698. Primefac (talk) 13:42, 22 April 2024 (UTC)

Numbers should start falling, I've undone the above. Primefac (talk) 13:50, 22 April 2024 (UTC)

FYI to @Uzume: — xaosflux ^Talk 14:19, 22 April 2024 (UTC)

@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). —Uzume (talk) 14:31, 22 April 2024 (UTC)

Hi 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 {{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. Primefac gave the answer while I was writing mine (@Primefac: Thank you). --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 insource:/invoke:params/, as seen here. 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. — xaosflux ^Talk 14:21, 22 April 2024 (UTC)

Thank you both @Primefac and @Xaosflux! The next changes in the code will pass through a sandbox. --Grufo (talk) 14:30, 22 April 2024 (UTC)

Ready for general use

Improvements are always possible, but I believe time has come to mark this module as ready for general use. --Grufo (talk) 18:52, 22 May 2024 (UTC)