Page MenuHomePhabricator

Parser Functions should support named parameters
Open, Needs TriagePublic


To quote :

Parser functions do not support named parameters the way templates and tag extensions do, but it is occasionally useful to fake it.

For uniformity of template syntax parsing, and to prevent continued slightly-incompatible wheel reinvention, we should fix this. When a parser function is registered with SFH_NAMED_ARGS as a flag to [Parser::setFunctionHook]( standardized parsing of named arguments should be done by core. Users should be encouraged to migrate to this.

We should think carefully through the desired behavior for whitespace-stripping of argument values, and ensure it makes sense with T114432: [RFC] Heredoc arguments for templates (aka "hygienic" or "long" arguments).

Event Timeline

cscott created this task.Sep 14 2018, 9:29 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 14 2018, 9:29 AM
Anomie added a subscriber: Anomie.Sep 14 2018, 3:58 PM

I note that the code at that link seems a bit outdated. A parser function that wants named arguments today should probably use SFH_OBJECT_ARGS and use PPNode->splitArg(), more or less like PPFrame_Hash::newChild() does or like Parser::braceSubstitution() does for special page transclusion.

That's not to oppose this task, I think a new SFH_NAMED_ARGS flag to make it even easier for implementers would be a good idea.

Thanks for the feedback!

When opting in to "standard" named argument parsing, you might want to opt-in to replacing the first colon with a vertical bar to look even more like a "standard" template invocation: T204371: Replace initial colon in (hash-prefixed) parser function invocation with vertical bar.