[Feature] Define short alias names for all keys supported in calculated-property definitions#8430
[Feature] Define short alias names for all keys supported in calculated-property definitions#8430mklement0 wants to merge 5 commits intoPowerShell:masterfrom
Conversation
Defines short alias names for all supported keys, for unambiguous short alternatives to the full key names.
|
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. |
|
@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. |
|
Thanks for the feedback, @joeyaiello.
Well, "canonicalizing" these aliases was the primary motivation for this PR: the intent was to future-proof the existing practice of using just Doing so follows the existing practice of providing parameter aliases such as 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. |
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:
lforlabelnfornameeforexpressionfforformatStringdfordepthaforalignmentwforwidthThe only exceptions:
ascforascendingdescfordescendingShould the latter two just be
aanddtoo? It's a possibility, given that the conflicting names,d(epth)anda(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
examplekey still unambiguously mapsetoexpression, whereas using the ambiguousexshould throw an exception?As before, there is no formal check for duplicate names / aliases; while maintaining all constants in class
CalculatedPropertyDefinitionKeyshelps, 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
.h,.cpp,.cs,.ps1and.psm1files have the correct copyright headerWIP:to the beginning of the title and remove the prefix when the PR is ready.[feature]if the change is significant or affects feature tests