[Feature] Define short alias names for all keys supported in calculated-property definitions

[mklement0]

PR Summary

Implements #8429.

Defines short alias names for all keys supported in calculated-property definitions, so that these aliases can be used safely, without fear of keys introduced in the future making previously unambiguous name prefixes ambiguous.

Note:

• A single internal class, CalculatedPropertyDefinitionKeys, now defines all supported keys (entries) across all cmdlets, and all future keys should be added there as well.

• Most alias names are single-character names:

  • l for label
  • n for name
  • e for expression
  • f for formatString
  • d for depth
  • a for alignment
  • w for width

• The only exceptions:

  • asc for ascending
  • desc for descending

Should the latter two just be a and d too? It's a possibility, given that the conflicting names, d(epth) and a(lignment) only apply to other cmdlets, or is cross-cmdlet consistency more important?

• Tests: Currently, no two keys for a given cmdlet start with the same letter, so how would we write a test that ensures, for instance, that adding an example key still unambiguously maps e to expression, whereas using the ambiguous ex should throw an exception?

• As before, there is no formal check for duplicate names / aliases; while maintaining all constants in class CalculatedPropertyDefinitionKeys helps, I wonder if we need a formal check to prevent duplicates - ideally as part of testing.

• Includes the changes for Allow 'name' as an alias key for 'label' in ConvertTo-Html, allow the 'width' entry to be an integer #8426 and Make scriptblock-based calculated properties work again in ConvertTo-Html #8427.

PR Checklist

• PR has a meaningful title
  • Use the present tense and imperative mood when describing your changes
• Summarized changes
• Change is not breaking
• Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
• This PR is ready to merge and is not Work in Progress.
  • If the PR is work in progress, please add the prefix WIP: to the beginning of the title and remove the prefix when the PR is ready.
• User-facing changes
  • Not Applicable
  • OR
  • User-facing Documentation needed
    • Issue filed - Issue link:
• Testing - New and feature
  • Not Applicable or can only be tested interactively
  • OR
  • Make sure you've added a new test if existing tests do not effectively test the code changed
    • Add [feature] if the change is significant or affects feature tests

[stale]

This PR has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed if no further activity occurs within 10 days.
Thank you for your contributions.
Community members are welcome to grab these works.

[joeyaiello]

@PowerShell/powershell-committee had a long discussion on this: a couple of us are ambivalent, and a couple feel like "canonicalizing" these aliases might encourage their usage in scripts (prompting the need to write a PSSA rule that no one wants to write).

Furthermore, no one expects any new keys to be added to this syntax in the future. (Though, personally, I might feel differently if you were planning on adding a host of new keys soon.)

Another possible option would be to add support for tab completion inside of the expression syntax, and everyone agrees that this would solve the meta problem of wanting to be relatively pithy on the command line, even if single-letter collisions occur after the addition of new keys.

[mklement0]

Thanks for the feedback, @joeyaiello.

a couple feel like "canonicalizing" these aliases might encourage their usage in scripts

Well, "canonicalizing" these aliases was the primary motivation for this PR: the intent was to future-proof the existing practice of using just n / l and e in scripts, based on a preponderance of such usage online.

Doing so follows the existing practice of providing parameter aliases such as -h for -Hidden in Get-ChildItem and the recently introduced (disclaimer: suggested by yours truly) -lp for -LiteralPath; similarly, the CLI offers -c as an alias for -command, ...

As an aside: Regrettably, these aliases are undocumented.

On a related note: it's worth entertaining a simpler syntax for calculated properties - see #8107

---

Leaving the alias aspect aside, this PR offered a worthwhile consolidation of all calculated-property keys in a single place, across all cmdlets.