Editing Module talk:Unsubst (section)

== Page protections and code architecture ==

This module seems really poorly architected. I do not mean to slight anyone that has worked on this as it is a very useful concept and I realize it was sort of organically developed but this lack of architectural foresight now has significant implications that I want to point out. This module is heavily used to prevent template substitutions but in its 12 million plus transclusions it is basically doing nothing except getting out of the way (i.e., yielding its {{para|$B}}), however, the majority of the logic in this module comes into play during substitutions (which by definition go away at page save time) and yet the entire module is fully protected from any changes by anyone but administrators.

It seems to me it would be much more useful to develop a module that does the unsubst'ing and another module that checks for substitution and either gets out of the way or loads (on demand) the unsubst'ing module to generate a template invocation that us not {{code|subst:}}ed. The "get out of the way under normal transclusion" module can be a fully protected stub module transcluded upon millions of pages while the unsubst'ing module can be (mostly) unprotected because it is transcluded nowhere (because that is what substitution means).

In any event, I wanted to record my thoughts on the subject until someone comes up with a better solution (which might be me if I get the time since I am thinking about this). —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 16:04, 12 October 2024 (UTC)
:@[[User:Uzume|Uzume]] I would be happy to port over my completely different implementation at [[wikt:Module:unsubst]] which indeed isn't transcluded on any pages, despite protecting templates which are invoked many millions of times.
:{{pb}}
:The way it works for module-based templates is to have something like this at the top level in the modules which need to be protected, which means it's never called if it's not needed:<syntaxhighlight lang=lua>if mw.isSubsting() then
	return require("Module:unsubst") 
end</syntaxhighlight>
:There are two issues which need to be considered in doing this, though:
:# I haven't got a ready-made template wrapper which does this for non-Lua templates, but it wouldn't be especially difficult to write one.
:# The if-block implementation assumes that the module it's in is only ever called via <code>#invoke</code> (i.e. that it's not called from other modules, which would result in breakage), which fits Wiktionary's module architecture, but may not be suitable in all Wikipedia modules. However, this shouldn't be too difficult to adapt as appropriate.
:[[User:Theknightwho|Theknightwho]] ([[User talk:Theknightwho|talk]]) 23:07, 4 August 2025 (UTC)
::@[[User:Theknightwho|Theknightwho]]: I haven't thought about this for a while now but thanks for the feedback. Even though we sort of already have the key requirement in {{tlx|ifsubst}} and it should not be that hard to implement a template based on that that either calls {{code|#invoke}} or returns the "body" or an error which could be protected and should not need much further development freeing the module to do just the wikitext template invocation construction, that won't really work as the wikitext generation module needs access to the parent frame which would be lost if there was another template in between. To that end, we {{em|do}} need a single "get out of the way" module that would then be able to do something like the code you provided above. I always like reading your code even when I am confused by how you write it. For example, [[wikt:Module:pages#L-101]] could be simplified to just <syntaxhighlight lang=lua inline>if type(val) ~= "table" then</syntaxhighlight> because it is not an error to call {{code|lang=lua|type}} on {{code|lang=lua|nil}} (or any value; it does throw an error if no value is provided though so <syntaxhighlight lang=lua inline>type(fn())</syntaxhighlight> might be dangerous; a clear difference using expression lists and varargs vs. assignment and function parameters where empty values are implicitly converted to {{code|lang=lua|nil}}). The same logic can be applied to simplify [[wikt:Module:pages#L-108--L-109]] too. I often prefer to not test for {{code|lang=lua|nil}} but just check something is the type I expect and move on. I doubt the comparison prior to the call to {{code|lang=lua|type}} buys you much in terms of speed. I know Lua employs [[string interning]] (sort of like memoization) for the creation of all strings which are immutable. This means every string is compared to all the others via hash tables at creation time and that for every string with a certain value there is only a single instance. That makes {{code|lang=lua|1=~=}} and {{code|lang=lua|1===}} very fast  for strings (i.e., literally only a reference comparison since interning guarantees no two strings can be equal unless they are the same reference). Since the results of {{code|lang=lua|type}} are severely limited, I imagine such string construction overhead is minimal and probably based upon literals. Anyway, I got off on a tangent. Thanks for the pointer to your [[wikt:Module:unsubst]] implementation. I think I meant to look at that anyway. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 01:51, 5 August 2025 (UTC)
::The problem with your [[wikt:Module:unsubst]] is that it allows transclusions with its {{mlx|unsubst|me|{{=}}...}} syntax so that transclusion stub will eventually get used and eventually the module will end up protected like this one is either due to a large number of transclusions and/or sensitive ones (via a cascade).
::I was thinking of a super simple stub similar to your {{code|me}} stub like:
::<syntaxhighlight lang=lua>
if mw.isSubsting() then
	local frame= mw.getCurrentFrame()
	return require("Module:" .. frame.args[''] or mw.wikibase.getSitelink('Q15243885'))
end
local mt = {}
function mt:__index(key)
	return function(frame)
		return key
	end
end
return setmetatable({}, mt)
</syntaxhighlight>
::And maybe call this [[Module:Unsubststub]] (or perhaps with your nomenclature [[Module:Unsubstme]]). This would allow something similar to your [[wikt:Module:unsubst]] but without the {{code|me}} transclusion stub (instead always generating an error during transclusions) and this stub code is simple and flexible enough that protections due to high transclusion counts, etc. would not be an issue. It would also allow for potentially different kinds of unsubsting wikitext generation modules to be used for different formats, etc. (e.g., this module vs. [[Module:Unsubst-infobox]], etc.) I appreciate your impressive [[wikt:Module:template parser]] but it is a little heavy compared to this module (although it does seem to only be called during the substing path so the impact is to page save and not to page render). —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 16:31, 5 August 2025 (UTC)