-
Notifications
You must be signed in to change notification settings - Fork 7.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[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 #8430
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:
l
forlabel
n
forname
e
forexpression
f
forformatString
d
fordepth
a
foralignment
w
forwidth
The only exceptions:
asc
forascending
desc
fordescending
Should the latter two just be
a
andd
too? 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
example
key still unambiguously mapse
toexpression
, whereas using the ambiguousex
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
.h
,.cpp
,.cs
,.ps1
and.psm1
files 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