Zobrazení zdroje stránky Diskuse k modulu:Yesno

{{permprot}}
{{copied|from=Module:Yesno|from_oldid=828075573|to=:incubator:Module:Wp/nod/Yesno|to_diff=4237022}}
==Testcases and documentation==
<pre>
{| class="wikitable"
|+ Test Cases (via [[Template:Yesno/doc]])
|-
! Module output
! Template output
! Expected
|-
| {{#invoke:Yesno|yesno|yes}}
| {{yesno|yes}}
| yes
|-
| {{#invoke:Yesno|yesno|YeS}}
| {{yesno|YeS}}
| yes
|-
| {{#invoke:Yesno|yesno|Y}}
| {{yesno|Y}}
| yes
|-
| {{#invoke:Yesno|yesno|y}}
| {{yesno|y}}
| yes
|-
| {{#invoke:Yesno|yesno|no}}
| {{yesno|no}}
| ''(blank)''
|-
| {{#invoke:Yesno|yesno|}}
| {{yesno|}}
| ''(blank)''
|-
| {{#invoke:Yesno|yesno}}
| {{yesno}}
| ''(blank)''
|-
| {{#invoke:Yesno|yesno|¬}}
| {{yesno|¬}}
| ''(blank)''
|-
| {{#invoke:Yesno|yesno|purplemonkeydishwasher}}
| {{yesno|purplemonkeydishwasher}}
| yes
|-
| {{#invoke:Yesno|yesno|yes|yes=bacon}}
| {{yesno|yes|yes=bacon}}
| bacon
|-
| {{#invoke:Yesno|yesno|no|no=ham}}
| {{yesno|no|no=ham}}
| ham
|-
| {{#invoke:Yesno|yesno|blank= eggs}}
| {{yesno|blank= eggs}}
| 
|-
| {{#invoke:Yesno|yesno|no=ham}}
| {{yesno|no=ham}}
| 
|-
| {{#invoke:Yesno|yesno|blank= eggs|no=ham}}
| {{yesno|blank= eggs|no=ham}}
| 
|-
| {{#invoke:Yesno|yesno|¬|¬=sausage}}
| {{yesno|¬|¬=sausage}}
| sausage
|-
| {{#invoke:Yesno|yesno|purplemonkeydishwasher|def=cup-of-tea}}
| {{yesno|purplemonkeydishwasher|def=cup-of-tea}}
| cup-of-tea
|-
| {{#invoke:Yesno|yesno|purplemonkeydishwasher|yes=bacon}}
| {{yesno|purplemonkeydishwasher|yes=bacon}}
| bacon
|-
| {{#invoke:Yesno|yesno|purplemonkeydishwasher|def=cup-of-tea|yes=bacon}}
| {{yesno|purplemonkeydishwasher|def=cup-of-tea|yes=bacon}}
| cup-of-tea
|-
| {{#invoke:Yesno|yesno|yes|yes=no|no=yes}}
| {{yesno|yes|yes=no|no=yes}}
| no
|-
| {{#invoke:Yesno|yesno|no|yes=no|no=yes}}
| {{yesno|no|yes=no|no=yes}}
| yes
|-
| {{#invoke:Yesno|yesno| no |no=no}}
| {{yesno| no |no=no}}
| no
|}
</pre>
:<small>Note: Pre tags added to suppress script errors. — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr. Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪ talk ♪]]</sup> 14:25, 20 September 2013 (UTC)</small>

As you can see, the template does not behave exactly as its documentation claims it does. I was not sure which to regard as authoritative: the ideal or actual implementation. I ultimately went with the former. Removing <code>and not any</code> from the Lua code will make the module behave like exactly like the template.

--[[User:Ori.livneh|Ori.livneh]] ([[User talk:Ori.livneh|talk]]) 10:46, 28 February 2013 (UTC)

:Just needs to handle spaces in the params better. -- [[User:WOSlinker|WOSlinker]] ([[User talk:WOSlinker|talk]]) 11:41, 2 March 2013 (UTC)
::Thanks. Fixed. I moved your test case to the table above. --[[User:Ori.livneh|Ori.livneh]] ([[User talk:Ori.livneh|talk]]) 05:58, 3 March 2013 (UTC)
:::Yesno has ~8M transclusions. No question it should handle the legacy 1:1. Test it. -[[User:DePiep|DePiep]] ([[User talk:DePiep|talk]]) 22:31, 11 March 2013 (UTC)
The documentation is wrong. The "egg" example assumes thet the input value is ''blank''. But in the code examples the input parameter is ''omitted''. Compare: 
* <nowiki>{{yesno|blank= eggs|no=ham}}</nowiki> →  {{yesno|blank= eggs|no=ham}} 
* <nowiki>{{yesno||blank= eggs|no=ham}}</nowiki> →  {{yesno||blank= eggs|no=ham}} 
This is what is actually documented:
* <nowiki>{{yesno|blank= eggs|no=ham|¬=bread}}</nowiki> →  {{yesno|blank= eggs|no=ham|¬=bread}}
:I have changed the documentation. Not the table above. -[[User:DePiep|DePiep]] ([[User talk:DePiep|talk]]) 13:16, 23 March 2013 (UTC)

== Why? ==

{{tl|yesno}} is quite simple, so I'm not sure if there is a point in replacing it with functionally equivalent Lua.  There are many cases where Lua can be much faster and easier to read, but I'm not sure that is the case here.  In fact, because of the slight overhead with #invoke, simple parser functions can actually be slightly faster than the equivalent Lua.  I haven't tested that here, but I wouldn't be surprised if there is no performance advantage in a case like this.  Seems like a strange template to target for Lua conversion.  [[User:Dragons flight|Dragons flight]] ([[User talk:Dragons flight|talk]]) 14:57, 12 March 2013 (UTC)

It’s just for compatibility. For some weird reason, yesno might not work and this will.

 <span style="font-family:'Arial';">[[User:E Super Maker|E Super Maker]]</span> ([[User talk:E Super Maker|😲 shout]]) 15:47, 23 November 2019 (UTC)

== test failed ==
{{resolved}}
One fail found in unit test: value "1= ¬ " (with whitespace). Reason:whitespace not removed before this check. Possible solution; treat '¬' as a character, separate from nil. 
(if val == nil or val == '¬' then ...). -[[User:DePiep|DePiep]] ([[User talk:DePiep|talk]]) 11:54, 23 March 2013 (UTC)
* Another fail: input value="00". See [[Module talk:Yesno/testcases]]. -[[User:DePiep|DePiep]] ([[User talk:DePiep|talk]]) 12:56, 23 March 2013 (UTC)
: also fails when 1=0.0
: Suggestion: change <code>val = args[1]</code> into <code>val = tostring(args[1])</code>. To prevent treating "000" as number. -[[User:DePiep|DePiep]] ([[User talk:DePiep|talk]]) 14:09, 23 March 2013 (UTC)
Solved. Module is changed, although the numeric issue different from my (incorrect) suggestion. -[[User:DePiep|DePiep]] ([[User talk:DePiep|talk]]) 14:19, 23 March 2013 (UTC)
:Thanks for putting the test cases up. I learned something new about ParserFunctions. :) Still seems to be slower than the old template version though. — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr. Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪ talk ♪]]</sup> 14:38, 23 March 2013 (UTC)

== Null? ==

The code now says {{code|1=<nowiki>no    = "<!-- null -->"</nowiki>}}. But a "" (nullstring) is not the same as ASCII NULL (0x0000). Also I see no use for adding wiki comment to code this way. -[[User:DePiep|DePiep]] ([[User talk:DePiep|talk]]) 17:47, 23 March 2013 (UTC)
:Yes, I agree that it doesn't really make sense. It's just in there to be 100% backwards-compatible with the current template. Those html comments should really have been removed from {{tl|yesno}} when it was made subst-able, which would have prevented us from having to second-guess whether they actually affect the output of any substitutions in any meaningful way. I suppose it's possible to download a database dump and to run a search on it to find out, but that's probably a bit much for my poor ailing laptop. Or we could just remove the comments and hope nothing breaks - I'm fairly sure that no-one would have written any template code that purposefully used them. There's no way to be sure that there is no code that was inadvertently written to be dependent on the error, though, and that worries me. — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr. Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪ talk ♪]]</sup> 18:24, 23 March 2013 (UTC)
::Drop it. Come what may. -[[User:DePiep|DePiep]] ([[User talk:DePiep|talk]]) 00:17, 24 March 2013 (UTC)

== Rewrite ==

I've rewritten this as a pure Lua function. The new version is a lot simpler, and is also designed to work with Lua data types such as booleans, tables, and functions. Dragons flight's criticism above is well-founded, and giving up on the idea of replacing {{tl|yesno}} seemed like the best answer. The new version should hopefully retain the basics of {{tl|yesno}} while playing well with Lua, and allow meta-modules that deal with boolean-style wikitext input to be consistent with each other. (In other words, users won't have to remember whether it was "category=yes" or "category=true" - it should Just Work<sup>TM</sup>.) — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr. Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪ talk ♪]]</sup> 14:37, 20 September 2013 (UTC)

== All testcases failed ==

is there some issue with the module, all tests on the [[Module talk:Yesno/testcases]] has failed. --[[User:Jarekt|Jarekt]] ([[User talk:Jarekt|talk]]) 16:37, 20 December 2013 (UTC)

== Protected edit request on 24 February 2014 ==

{{edit protected|<!-- Page to be edited -->|answered=yes}}
<!-- Begin request -->the information is deceptive

<!-- End request -->please delete
[[Special:Contributions/2600:1013:B018:986F:4493:7A2A:52E2:103A|2600:1013:B018:986F:4493:7A2A:52E2:103A]] ([[User talk:2600:1013:B018:986F:4493:7A2A:52E2:103A|talk]]) 04:21, 24 February 2014 (UTC)
:[[File:Red question icon with gradient background.svg|20px|link=|alt=]] '''Not done:''' please be more specific about what needs to be changed.<!-- Template:EP --> Note that this is the talk page for [[Module:Yesno]] and there is no information here.  What information on which page do you think is deceptive? — <span class="nowrap">&#123;&#123;U&#124;[[User:Technical 13|Technical 13]]&#125;&#125;</span> <sup>([[User talk:Technical 13|t]] • [[Special:EmailUser/Technical 13|e]] • [[Special:Contributions/Technical 13|c]])</sup> 04:27, 24 February 2014 (UTC)

== New version ==

I've put a new version of this module in the sandbox. The new version uses the native Lua string.lower function instead of the Scribunto mw.ustring.lower function. According to my tests it is about 25x faster this way. Would anyone object to me updating the module? — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr. Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪ talk ♪]]</sup> 15:22, 7 April 2014 (UTC)
:I see no issue with it. [[User:Jackmcbarn|Jackmcbarn]] ([[User talk:Jackmcbarn|talk]]) 18:57, 7 April 2014 (UTC)
::The new version is live as of the 18th. — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr. Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪ talk ♪]]</sup> 12:33, 22 April 2014 (UTC)

== Doc questions (blank string true/false) ==

# In the documentation, I changed the "nil" example into singular. Or are there are other forms of nil covered and to be documented? (uppercase?, a non-initialised variable?).
# The last paragraph is about the <code><nowiki>''</nowiki></code> value (blank string). It says:
:''Although the blank string usually evaluates to false in wikitext, it evaluates to true in Lua.'' Is this correct here?

:According to this same documentation, it is treated as "not a boolean". It says it returns the default (parameter) value, not the 'true' value. That is: not recognised as a boolean, iic. And elsewhere the doc says "<code><nowiki>yesno('')</nowiki></code> returns nil". (I did not test any). -[[User:DePiep|DePiep]] ([[User talk:DePiep|talk]]) 09:06, 8 April 2014 (UTC)

::On nil: there is only one kind of nil. However, there may be many variables in any given module whose value may be nil, hence "nil values". There is no "uppercase nil", and in Lua there is no such thing as a non-initialised variable, as variables are initialised when they are first used. On the blank string: saying that it "evaluates to true" is talking about when it is used in if/then statements or with the <code>and</code> and <code>or</code> operators. For example, the following code will return true:
<syntaxhighlight lang="lua">
if '' then
	return true
else
	return false
end
</syntaxhighlight>
::Does that clear things up? — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr. Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪ talk ♪]]</sup> 09:26, 8 April 2014 (UTC)
:::Does it clear things up? Don't know. Documentation did not change. -[[User:DePiep|DePiep]] ([[User talk:DePiep|talk]]) 12:10, 8 April 2014 (UTC)
::::I mean, do you understand it now? — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr. Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪ talk ♪]]</sup> 12:34, 8 April 2014 (UTC)

== Render T as true as well? ==

I have seen some applications use T as an option for true as well. It might, therefore, be useful to have the letter T (t) represent a true value as well. <span style="border:1px solid maroon; padding:0 2px">[[User:CRwikiCA|<span style="font-family:'Courier';color:maroon">CRwikiCA</span>]]&nbsp;[[User talk:CRwikiCA|<i style="color:navy">talk</i>]]</span> 15:15, 14 April 2015 (UTC)
;Request
{{edit protected|ans=y}}
I request a change to the module to recognize T or t and F or f as true and false entries. This would make the full code the following:
<syntaxhighlight lang="lua" line>
-- Function allowing for consistent treatment of boolean-like wikitext input.
-- It works similarly to the template {{yesno}}.

return function (val, default)
	-- If your wiki uses non-ascii characters for any of "yes", "no", etc., you
	-- should replace "val:lower()" with "mw.ustring.lower(val)" in the
	-- following line.
	val = type(val) == 'string' and val:lower() or val
	if val == nil then
		return nil
	elseif val == true 
		or val == 'yes'
		or val == 'y'
		or val == 'true'
		or val == 't'
		or tonumber(val) == 1
	then
		return true
	elseif val == false
		or val == 'no'
		or val == 'n'
		or val == 'false'
		or val == 'f'
		or tonumber(val) == 0
	then
		return false
	else
		return default
	end
end
</syntaxhighlight>
Where lines 15 and 23 are new compared to the current code. <span style="border:1px solid maroon; padding:0 2px">[[User:CRwikiCA|<span style="font-family:'Courier';color:maroon">CRwikiCA</span>]]&nbsp;[[User talk:CRwikiCA|<i style="color:navy">talk</i>]]</span> 18:17, 23 April 2015 (UTC)
:No opposition, so {{done}} &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 10:43, 27 April 2015 (UTC)
::I would be interested to know cases where such "t/f" values may be encountered. I know that in command prompts we may encounter "y/n" choices. But I cannot recall having ever encountered "t/f".
::Refs [[phab:T137584|T137584]] (« Allow Scribunto code to add a category without changing output »), which would allow to know on what (and how many) pages these values are actually used.
::[[User:Od1n|Od1n]] ([[User talk:Od1n|talk]]) 00:05, 20 October 2024 (UTC)

== Support on/off detection ==

{{edit fully-protected|answered=yes}}
Please add support for {{kbd|on}} and {{kbd|off}} values (as equivalents of {{kbd|1}} and {{kbd|0}}, respectively), for consistency with the regular-template version {{tlx|Yesno}}, per RfC at [[Template talk:Yesno#Support on/off detection]]. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''']] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] 😼 </span> 23:44, 22 February 2018 (UTC)
:Very simple change, but i've [[Module:Yesno/sandbox|sandboxed]] the change and ran the testcases.. [[User:Galobtter|Galobtter]] ([[User talk:Galobtter|pingó mió]]) 07:52, 25 February 2018 (UTC)
:[[File:Yes check.svg|20px|link=|alt=]] '''Done'''<!-- Template:EP --> &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 12:14, 28 February 2018 (UTC)
::Thank you {{U|Galobtter}}, for the coding work (Lua gives me a headache), and {{U|MSGJ}}, for just getting it implemented, instead of either of you being a thorn in the side about it like several parties were for no defensible reason at the RfC. I've never encountered so much "resist sensible change just because I feel like it" nonsense on a minor technical matter as I did in this particular case.  It was weird, verging on inexplicable. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''']] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] 😼 </span> 18:37, 26 May 2018 (UTC)

== Upgrade of protection level ==

I believe we should make this template editor protected (I've seen templates with way less of the amount of transclusions than this one being template protected). Just a suggestion before I would put it up in the list. [[User:KylieInTheSkylie|KylieInTheSkylie]] ([[User talk:KylieInTheSkylie|talk]]) 02:23, 6 April 2020 (UTC)
:Just realized that full protection is not [[wp:ECP| Extended confirmed protection.]] Please disregard this. [[User:KylieInTheSkylie|KylieInTheSkylie]] ([[User talk:KylieInTheSkylie|talk]]) 02:23, 6 April 2020 (UTC)

== Multilingual version? ==

What about a multilingual version? Would there be any conflicts? [[User:Trigenibinion|Trigenibinion]] ([[User talk:Trigenibinion|talk]]) 17:21, 12 March 2021 (UTC)
:It seems this is normally called the same in other languages, where they appear to tend to support English as well as the translation, so this should be usable in a multilingual module. [[User:Trigenibinion|Trigenibinion]] ([[User talk:Trigenibinion|talk]]) 17:57, 12 March 2021 (UTC)
:: There is no need for a multilingual version of this module to exist on this wiki, since its content is in only one language. Furthermore, were one created, it would be a recreation of [[Module:YesnoTNT]], which was deleted per [[Wikipedia:Templates for discussion/Log/2019 December 11#Module:YesnoTNT]], and I would move for it to be speedy deleted per [[WP:CSD#G4]] [[User:Pppery|* Pppery *]] [[User talk:Pppery|<sub style="color:#800000">it has begun...</sub>]] 20:36, 13 March 2021 (UTC)

== Option: Binary-only? ==

I want to "propose" to add an option (feature) that makes the module return '''{{code|T/F}} only, never {{code|nil}}'''. For example, it could have para {{para|whennil|&lt;True or False>}}.

The background is that there are many situations (I meet in programming Lua) where a 'nil' return value is not helpful and still has to be handled separately into binary logic.

But even better, maybe I can ''learn'' why this was not added from the start, or why it could be considered bad design/coding. Maybe it could be solved by creating a wrapper like "Module:YesnoNevernil", or is that bad design again? -[[User:DePiep|DePiep]] ([[User talk:DePiep|talk]]) 04:56, 23 December 2021 (UTC)

:It's easy enough to just handle the nil in your own code, for example: <syntaxhighlight lang="lua" inline>myvariable = yesno(value) or false</syntaxhighlight> -- [[User:WOSlinker|WOSlinker]] ([[User talk:WOSlinker|talk]]) 20:09, 23 December 2021 (UTC)
::This can also mostly be handled by specifying the default parameter (i.e. <syntaxhighlight lang="lua" inline>myvariable = yesno(value, false)</syntaxhighlight>), although this does leave the case <syntaxhighlight lang="lua" inline>yesno(nil, false)</syntaxhighlight>, which evaluates to <syntaxhighlight lang="lua" inline>nil</syntaxhighlight>. The reason I originally programmed the module this way is so that it can be mostly backwards-compatible with [[Template:Yesno]], which it is intended to replace. Originally the plan was to do a straight conversion of [[Template:Yesno]] to Lua, but it turned out that doing that was actually slower than just using the template, given the template's simplicity and the initial cost of switching between PHP and Lua. So instead this module became Lua-only, with most of the behaviour of [[Template:Yesno]]. The intention there was that module writers could easily incorporate it into modules that convert more complex templates without having to change the template logic too much. — '''''[[User:Mr. Stradivarius|<span style="color: #194D00; font-family: Palatino, Times, serif">Mr.&nbsp;Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪&nbsp;talk&nbsp;♪]]</sup> 22:11, 23 December 2021 (UTC)
:::OK, thx. I can use this code solution with confidence now, no research-&-test needed. Might as well add it to the /doc. -[[User:DePiep|DePiep]] ([[User talk:DePiep|talk]]) 16:35, 24 December 2021 (UTC)
::::The abovementioned <code>yesno(value) or true/false</code> has a common pitfall and should be avoided: if value is "false", <code>yesno(value) or true</code> would gives "true", instead of the presumably expected "false". See section « Standard solution: and/or » on [http://lua-users.org/wiki/TernaryOperator this page]. [[User:Od1n|Od1n]] ([[User talk:Od1n|talk]]) 18:15, 22 September 2024 (UTC)

== Edit request 25 September 2025 ==

{{Edit fully-protected|answered=yes}}

'''Description of suggested change:''' Please merge [[Module:Yesno/sandbox]]. Uses a [[lookup table]] instead of an if-elseif-else statment which is almost 50% as fast as a lookup table as table lookups in Lua are O(1) average case.

I made a benchmark comparing exact current module with the new one: [[Module:Sandbox/Waddie96]]. To run, [https://en.wikipedia.org/w/index.php?title=Module:Sandbox/Waddie96&action=edit go into edit mode], in the LuaConsole type <code>'''<span style="color:darkblue;">=p.main()</span>'''</code>. Output compares the two with 500,000 iterations. My output showed almost 30–50% speed improvement which is a lot for a module transcluded [https://en.wikipedia.org/wiki/Special:WhatLinksHere/Module:Yesno on 31,723,438 pages].

<code style="display:block;" class="mw-code mw-highlight mw-highlight-lang-bash pre">'''<span style="color:darkblue;">=p.main()</span>'''
Running benchmarks with <span style="color:var(--color-subtle);">500000</span> iterations...
Lookup table took <span style="color:maroon;">3.6897</span> seconds for <span style="color:var(--color-subtle);">8500000</span> operations 
If-elseif chain took <span style="color:maroon;">5.0883</span> seconds for <span style="color:var(--color-subtle);">8500000</span> operations
</code>
'''Diff:''' [https://en.wikipedia.org/w/index.php?title=Module%3AYesno%2Fsandbox&diff=1313227532&oldid=1313226214 Diff here].


<span class="fn nickname" style="color:#CD0000">[[User:Waddie96|waddie96]] ★ ([[User talk:Waddie96|talk]])</span> 01:36, 25 September 2025 (UTC)
: So you're saving about 165 nanoseconds per call, and it's unlikely this is getting called so many thousands of times that that really adds up? That's not terribly convincing. OTOH, other than oddly assigning <code>TO_NUMBER = tonumber</code> and <code>TYPE = type</code> without any explanation, it seems like an ok increase in clarity to have almost all the accepted values together at the top. You might go a little further and stick boolean true and false into <code>BOOLEAN_MAP</code> and skip checking types at all, as Lua doesn't do any type conversion on table keys and allows anything except nil and NaN. [[User:Anomie|Anomie]][[User talk:Anomie|⚔]] 01:58, 25 September 2025 (UTC)
:: [[WP:PERF]]. Probably the amount of time it would take for the parser to reparse almost every page on the project triggered by this edit would greatly exceed the time saved for the forseeable future. And the code as is seems plenty clear enough, so I'm not seeing the clarity argument either. I'm contesting this request. [[User:Pppery|* Pppery *]] [[User talk:Pppery|<sub style="color:#800000">it has begun...</sub>]] 02:25, 25 September 2025 (UTC)
:::This benchmark case isn't perfectly representitive. Generally, the average template call or invoke from a page will use Yesno just a few times, repeated among a bunch of different template calls. That means, if a singular call ends up using YesNo ~5 times or less in total, the lookup table version technically has ''more'' overhead than the current simplistic implementation (upwards of ~2x slower, though that means little at this scale), due to the time it takes to create the lookup table and localise the globals every time. Also, as mentioned above, this is fighting to save milliseconds (if even that much) in the wrong place - it definitely won't be fixing any multi-second or 10s timeout pages, which is where optimisations matter. [[User:Aidan9382|Aidan9382]] <sub>([[User talk:Aidan9382|talk]])</sub> 08:19, 25 September 2025 (UTC)
::::Yes, you make an excellent point, so lets break it down: '''The economics of optimization at scale:'''
::::Saving time or indefinite use of the slower iteration?
::::[[Module:Yesno/sandbox]] refactored to use a lookup table <code>(BOOLEAN_MAP) → O(1)</code>, instead of nested if-elseif-else statements. This reduces the number of operations per call from ~7 to ~2.
::::If speedup per call is ~70%, you only need a few pageviews per page to amortize the reparse.
::::'''Impact on Wikimedia at scale:'''
::::* Pages affected: ~32 million transclusions
::::* Estimated calls per year: ~32 billion
::::* Aggregate operations saved: ~160 billion operations/year
::::* Speedup per call: 71%
::::* Even if we consider just one pageview per page, the benefit already exceeds the cost.
::::'''Ongoing benefit:'''
::::That doesn't only affect the next child down that uses this module, but:
::::* Every single page view that uses this module gets the speedup
::::* Every edit that triggers reparsing gets the speedup
::::* Every template expansion gets the speedup
::::'''Savings (rough estimates):'''
::::* '''Time saved per CPU:''' ~80 seconds/year (per CPU handling pageviews)
::::* '''Real-world effect:''' reduced CPU load, faster page loads for millions of pageviews
::::'''Break-even on one-time reparse cost:'''
::::* Only '''2–3 pageviews per transcluded page''' are required to offset the one-time parsing cost
::::* For Wikimedia’s scale (~4,500 views/second), the break-even is achieved in '''~3 hours''' for the first affected pages{{efn|Each page using the yesno module only needs to be viewed/edited 2-3 times after the optimization to break even. Approx. 1 day = 391 million views. ~= ''3 hours'' for 3 pageviews to break even on the reparse cost. As currently enwiki receives ~4,500 views per second. Estimate: 69 million edits and 143 billion page views in the previous year divided by (86,400 sec/day * 365 days).[https://stats.wikimedia.org/#/en.wikipedia.org/reading/total-page-views/normal|bar|1-year|~total|monthly] 12 billion page views just in Aug-Sept 2025 see [https://stats.wikimedia.org/#/en.wikipedia.org WikiStats].}}
::::'''Technical benefits:'''
::::* O(1) lookup vs O(n) linear search
::::* Function caching avoids repeated global access overhead
::::* Cleaner, more maintainable code
::::* Adding new values now only requires updating the lookup table
::::This optimization demonstrates how small changes in module logic can lead to aggregate performance improvements.
:::: <span class="fn nickname" style="color:#CD0000">[[User:Waddie96|waddie96]] ★ ([[User talk:Waddie96|talk]])</span> 05:44, 27 September 2025 (UTC)
::::@[[User:Aidan9382|Aidan9382]] I'm happy to fix those latter cases too going forward, point me in the right direction 😄 <span class="fn nickname" style="color:#CD0000">[[User:Waddie96|waddie96]] ★ ([[User talk:Waddie96|talk]])</span> 05:46, 27 September 2025 (UTC)
:::::Some comments:
:::::* The point is that there is no way to "fix" this, because nothing's broken. At the end of the day, you are trying to optimise 14 equality checks. Infact, the time it takes to require this module ''after it's been cached'' is longer than an average-case use of the if-else chain function. Even if this would technically improve the performance to the degree of nanoseconds on a bunch of pages (which isn't guaranteed per below), that is the wrong place to be looking for optimisations as a wikipedia editor. The focus should be on pages that spend a significant amount of time (upwards of multiple seconds) on lua evaluation, since that's when it can start to disrupt editing and reading, which is what we care about.
:::::* {{tq|Speedup per call: 71%}} is ''best case'' scenario, and as I've described above, is not always the case. Let's say you have a page that has <code><nowiki>{{T1|param=yes}}{{T2|param=no}}</nowiki></code> on it, and that each of these template calls eventually call into this module to check the value of <code>param</code>. Since both will create seperate lua states, both have to complete the initial uncached require on this module. That time increases significantly when adding a table creation, to the point where this specific setup would have Yesno spending ~2x more time executing than the current version.
:::::* The idea of {{tq|Every single page view that uses this module gets the speedup}} is incorrect - the evaluated state of pages are cached, and the majority of views will not cause a reevaluation, so the scale that you suggest this improvement is running at isn't accurate. Also, {{tq|Every template expansion gets the speedup}} is essentially the prior two points reiterated.
:::::[[User:Aidan9382|Aidan9382]] <sub>([[User talk:Aidan9382|talk]])</sub> 12:21, 27 September 2025 (UTC)

{{notelist-talk}}