Content deleted Content added
→Multilingual version?: new section |
m Reverted edits by 205.207.203.15 (talk) (HG) (3.4.13) |
||
| (41 intermediate revisions by 31 users not shown) | |||
Line 167:
::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:
<
if '' then
return true
Line 173:
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)
Line 184:
{{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:
<
-- Function allowing for consistent treatment of boolean-like wikitext input.
-- It works similarly to the template {{yesno}}.
Line 215:
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>]] [[User talk:CRwikiCA|<i style="color:navy">talk</i>]]</span> 18:17, 23 April 2015 (UTC)
:No opposition, so {{done}} — Martin <small>([[User:MSGJ|MSGJ]] · [[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 ==
Line 235 ⟶ 238:
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|<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. Stradivarius</span>]]''''' <sup>[[User talk:Mr. Stradivarius|♪ talk ♪]]</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)
| |||