Page MenuHomePhabricator

Add `#or:` parser function
Open, LowestPublic

Description

For source code readability and probably also parsing speed it would be great if we had a parser function #or that would work like nested ifs:

{{#or:{{{title|}}}|{{{name|}}}|{{PAGENAME}}}}

for example would be equivalent to:

{{#if:{{{title|}}}|{{{title}}}|{{#if:{{{name|}}}|{{{name}}}|{{PAGENAME}}}}}}

So, #or: would work kind of like the null coalesce operator ?? in PHP. This example is a minimal case, where this parser function can be useful. More complicated examples, which often come up in more complex templates, would benefit even more.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 13 2018, 10:26 PM

If implemented it should have a better name than #or. At least for my understanding #or would be the same as {{#if:{{{title|}}}{{{name|}}}|Any of them is not empty|Both of them are empty}}, so a less confusing name would be better.

It would be really important to be able to validate much more real-world use-cases for this, as well as have links to talk pages where this have been requested by the community. I also have to support the previous comment: Just calling this "or" does not sound right.

If implemented it should have a better name than #or. At least for my understanding #or would be the same as {{#if:{{{title|}}}{{{name|}}}|Any of them is not empty|Both of them are empty}}, so a less confusing name would be better.

This isn't correct. As requested, the code {{ #or: {{{title|}}} | {{{name|}}} | {{PAGENAME}} }} would be equivalent to

{{ #if: {{{title|}}}
  | {{{title}}}
  | {{ #if: {{{name|}}}
    | {{{name}}}
    | {{PAGENAME}}
  }}
}}

Note that this means that {{{title}}} and {{{name}}} each have their own "this exists" branch, and the entire second branch (the check for {{{name}}} existing) would not be followed if {{{title}}} exists. This is a significant difference from your understanding.

I do agree the name #or is not ideal, though I'm short on suggestions for better names - the best I can come up with is some variant of "firstexists", but that doesn't seem very satisfactory.

Agabi10 added a comment.EditedAug 19 2018, 3:32 PM

If implemented it should have a better name than #or. At least for my understanding #or would be the same as {{#if:{{{title|}}}{{{name|}}}|Any of them is not empty|Both of them are empty}}, so a less confusing name would be better.

This isn't correct.

I know the requested behavior and my understanding don't match, what I tried to tell is what I would think the #or parser function would be doing when I found it in wikitext if implemented that way. That's something to take into account before setting that name to the function and preferably named differently to prevent that kind of confusions.

I do agree the name #or is not ideal, though I'm short on suggestions for better names - the best I can come up with is some variant of "firstexists", but that doesn't seem very satisfactory.

I think #firstexists would be way more descriptive than #or. The problem with that name is that it might create confusion with how #ifexists behaves. What about #coalesce as in many SQL databases?

I know the requested behavior and my understanding don't match, what I tried to tell is what I would think the #or parser function would be doing when I found it in wikitext if implemented that way. That's something to take into account before setting that name to the function and preferably named differently to prevent that kind of confusions.

Aah, my apologies for misunderstanding you then! ^^;

I think #firstexists would be way more descriptive than #or. The problem with that name is that it might create confusion with how #exists behaves. What about #coalesce as in many SQL databases?

I'm not familiar with #exists; did you mean #ifexists?

I figured there might be preexisting terminology for this type of functionality in some programming language or another, but had no idea what it might be or how to go about looking for it. Looking around a bit now that I have "coalesce", though, suggests this functionality is a variant of the null coalescing operator (maybe an extended Elvis operator?), so that name definitely makes sense. I am worried, though, about how intuitive it might be for people with little background in programming (though this might be an unavoidable issue no matter what name we choose).

I'm not familiar with #exists; did you mean #ifexists?

Yes, I just edited the answer to fix that.

I figured there might be preexisting terminology for this type of functionality in some programming language or another, but had no idea what it might be or how to go about looking for it. Looking around a bit now that I have "coalesce", though, suggests this functionality is a variant of the null coalescing operator (maybe an extended Elvis operator?), so that name definitely makes sense. I am worried, though, about how intuitive it might be for people with little background in programming (though this might be an unavoidable issue no matter what name we choose).

Yes, it's exactly that. And I don't think it's really a problem that it might be confusing for people with little background in programming. Once they get used to the naming it's less confusing than the existing <includeonly> and <onlyinclude> tags.

MGChecker added a comment.EditedAug 19 2018, 4:59 PM

I chose #or as possible name for a function like that, because it is used this way in many coding languages, for example:

So, I think it isn't that unintuitive. Furthermore, I think many parser functions defined in this extensions already don't have the most intuitive behavior themselves.

(Note that I didn'T see the last 3 hours of comments before submitting this.)

It would be really important to be able to validate much more real-world use-cases for this, as well as have links to talk pages where this have been requested by the community. I also have to support the previous comment: Just calling this "or" does not sound right.

It should be fairly easy to make a statistic how many (and how deeply) nested #if parser function occur on enwiki and some other sites.

I figured there might be preexisting terminology for this type of functionality in some programming language or another, but had no idea what it might be or how to go about looking for it. Looking around a bit now that I have "coalesce", though, suggests this functionality is a variant of the null coalescing operator (maybe an extended Elvis operator?), so that name definitely makes sense. I am worried, though, about how intuitive it might be for people with little background in programming (though this might be an unavoidable issue no matter what name we choose).

#coalesce would be another possible name, although I don't like that it's much longer than simply writing `#or'. An additional advantage of the latter that according to enwiki Lua uses a similar syntax for this thing, so it would be consistent with Scribunto.

So, finally catched up ^^

Krinkle added a subscriber: Krinkle.EditedAug 19 2018, 11:17 PM

I'd recommend addition of new parser functions, no matter the use case.

[..] Lua uses a similar syntax for this thing, so it would be consistent with Scribunto.

Since you mention Lua and Scribunto, did you encounter an issue with Lua that made you prefer wikitext?

EDIT: I meant to say, I'd recommend against addition of new parser functions.

I'd recommend addition of new parser functions, no matter the use case.

Did you accidentally a word there? Given we do have Scribunto and Lua now, I'd kind of expect you to be against addition of new parser functions, not in favor.

Since you mention Lua and Scribunto, did you encounter an issue with Lua that made you prefer wikitext?

I don't have any knowledge of Lua specifically, but just happened to notice this information. However, I recently got to know Lua a little bit while looking after T201171.

I prefer wikitext as it's more standard and more portable to third-party wikis than Lua. Furthermore, there are much more users who are able to work with wikitext templates than with Scribunto invocations.

I'd recommend addition of new parser functions, no matter the use case.

Did you accidentally a word there? Given we do have Scribunto and Lua now, I'd kind of expect you to be against addition of new parser functions, not in favor.

Assumed you both missed a word there: What is your rationale against the addition of new parser functions?

Indeed. I'd recommend against addition of new parser functions for logic and string operations.

Aklapper triaged this task as Lowest priority.Aug 24 2018, 9:54 AM
cscott added a subscriber: cscott.Tue, Sep 17, 4:40 PM
Restricted Application added a subscriber: Liuxinyu970226. · View Herald TranscriptTue, Sep 17, 4:40 PM