Repository navigation
Add support for dynamic parameter declaration in param() #16173
Description
Summary of the new feature / enhancement
Static parameters can easily be defined declarative inside a param() structure.
Dyamic parameter is not directly supported and must be programmed inside a dynamicparam section of a scriptblock. This requires deep knowledge of intrinsic types and concepts.
By adding a new attribute [Dynamic()], parameters can easily be declared as being dynamic. The attribute could take a scriptblock as argument to specify the condition under which the dynamic parameter would show.
param
(
# regular static parameter
[string]
$Normal,
# show -Lunch only at 11 a.m. or later
[Dynamic({(Get-Date).Hour -ge 11})]
[switch]
$Lunch,
# show -Mount only when -Path refers to a local path (and not a UNC path)
[string]
$Path,
[Dynamic({$PSBoundParameters['Path'] -match '^[a-z]:'})]
[switch]
$Mount
)Here is a working example and a proof of concept (hosted in the gallery) that shows how dynamic parameters could be leveraged this way:
It would be awesome if both the attribute [Dynamic()] and the auto-generation of the code would one day be natively integrated in PowerShell so users would just need to choose which of their parameters should be dynamic, and when.
Proposed technical implementation details (optional)
Technical implementation available here: https://github.com/TobiasPSP/Modules.dynpar/blob/main/README.md
Activity
jhoneill commentedon Feb 2, 2022
Dr. Tobias Weltner (@TobiasPSP) I saw this in the working group, but it's probably better to put my input here.
To me the main use case for dynamic parameters has always been the parameter which only appears if some condition is satisfied. It is a pain to have to refer to these through $psboundParameters because dynamic parameters aren't automatically accessible as
$ParamName. I would see just fixing that as a win.We already have a
DontShowmember for parameters which we want to be accepted by not suggested to the user; a "Don't show and error if it is given" option which is evaluated at run time would address the need for dynamically appearing / disappearing parameters. Something like[ArgumentCompleter( )]which takes either a type or a ScriptBlock , strikes me as ideal - especially if it took the same arguments.There are many cases where we want to say "If switch A is specified hide B and C" and we send people to parameter sets for that - which is OK if there is already only one parameter set - we put A in one set and B&C in another.
But if we already have multiple parameter sets like "By-ID" and "By-Name" we need to make "By-ID-withA" "By-ID-withoutA" and "By-Name-withA" "By-Name-withoutA", and put everything in the correct pair of sets. If we also want to hide Y and Z when X is shown, and we have By-Address as well name and ID we end up with 4 combinations of with/without A and X multiplied by 3 selections, and making sure everything has the right 3 or 4 from 12 becomes a nightmare. This suggestion could simplify parameter sets which would also be a win.
The biggest case where I have seen aspects of the parameter were built dynamically was the VSTeam (Azure DevOps) module - where validation sets were built on the fly with information fetched from the server.
Enumerating commands can cause their dynamic parameters to be generated and IIRC there were well over 100 of these parameters which meant
Get- [tab]caused the machine to stop while dozens of API calls were made and the results processed. So the Dynamic parameters became static parameters with classes doing the work.Without this case and the hide/show usage, the other build-at-run-time parameters I've met don't many common requirements and often need a lot of code which best kept out of the
param()block. I can imagine cases were we want other properties of the parameter to change dynamically for example-Pbecomes mandatory only if-Qhas a negative value. But is any a sufficient pain point to justify a change.I think " there/not there " is the case with real benefit, and it might be better to have name for this that is distinct from "dynamic" It's something in the same family as completers, transformers, and validators
TobiasPSP commentedon Mar 3, 2022
We discussed this in the cmdlet working group. The use of dynamic parameters is considered to be a functionality not commonly used by Powershell users. Those who need them can use the dynamicparam block as is, and optionally use generators or the suggested new attribute to generate the required code. Given the relatively small numbers of users who would benefit, this suggestion will not be implemented into the core engine.
jhoneill commentedon Mar 3, 2022
That probably is better use of limited resources, but still a pity.
This remains a good idea - dynamic parameters are not commonly used AND using them is so painful as things stand. I originally wrote BECAUSE instead of "AND" - I think there is a causal link, but I can't prove it.
I'm cross that I missed the discussion. I would like to know if there's a feeling that the need is small - that may be true, but I think there are people who are neither using parameter sets (because putting each of 10 parameters in the right combination of 10 sets is for Masochists only) nor using dynamic parameters (for similar reasons) and writing something inside a function to trap impossible combinations. If that is so then the low use of dynamic parameters is proof that this is needed, not that it isn't :-)
TobiasPSP commentedon Mar 6, 2022
I agree (no surprise since I suggested the feature enhancement in the first place) yet I do understand the resource issue. Unfortunately, this suggestion is one of the few that can't be implemented by the community as it requires the new attribute to be honored by the engine to make sense, and it doesn't appear to be a huge engineering effort. That said, it was discussed, and it was turned down at this time. Maybe in the future there is an opportunity to revisit.
dkattan commentedon Sep 8, 2023
Dr. Tobias Weltner (@TobiasPSP) I believe my PR here would be helpful but I need more community support: #20069