Repository navigation
Dynamic Parameters are too Difficult to Construct #20395
Description
Summary of the new feature / enhancement
As a heavy user of dynamic parameters, I often find myself tripping over their basic failures in constructability.
Dynamic Parameters are needlessly difficult to construct.
The shortest possible constructor is:
[Management.Automation.RuntimeDefinedParameter]::new("A", [psobject], @())and it fails in an entreatingly confusing way, informing me that I could not bind "A" to "AllParameterSets", without telling me why.
Dynamic Parameters should be easier to construct.
The need goes beyond simplifying existing implementation and fixing its buggier parts:
A very common scenario is exposing dynamic parameters from one command to another.
This should also be easier to construct
Proposed technical implementation details (optional)
- Add simplified constructors to
[Management.Automation.RuntimeDefinedParameter]- Constructing from only a name should create a
[PSObject]parameter that acceptsValueFromPipelineByPropertyName - Constructing from a name and a type should add an empty
[Parameter()]attribute
- Constructing from only a name should create a
- Allow
[Management.Automation.RuntimeDefinedParameter]to be coerced from[Management.Automation.ParameterMetadata] - Create extension methods to assist in custom conversion to
[Management.Automation.RuntimeDefinedParameter] - Enable adding dictionaries to
[Management.Automation.RuntimeDefinedParameterDictionary] - Adding type accelerators
[DynamicParameter],[DynamicParameters], so that less typing is required to create them.
Reacted by James O'Neill, Travis LaGrone and Darren Kattan
Activity
jhoneill commentedon Sep 29, 2023
Using Dynamic parameters has been painful as long as they have existed (e.g. they don't go to variables, you need to go to $psBoundParamaters to get them) it feels like bigger exercise than described in the first post
Improving Dynamic Parameter Construction (Fixes PowerShell#20395)
dkattan commentedon Oct 6, 2023
And they can't reference each other. I tried to get variable assignment and allowing them to reference each other approved but it was rejected. I really could use some help convincing the team.
#20069
Dynamic Parameter Construction - Fixing CodeFactor Suggestions (re Po…
TobiasPSP commentedon Nov 17, 2023
We discussed this a while ago in the cmdlets working group, and back then it was concluded there was not enough demand to improve creating dynamic parameters. Also we realized that we were the wrong working group for this topic :-)
Back then I created a proof of concept based on new attributes that makes adding dynamic parameters just as easy as static parameters:
https://github.com/TobiasPSP/Modules.dynpar
This would require adding new attributes to the engine. The example module linked can‘t do this so please follow the instructions to test-drive it. Since the module needs to define and process the new attributes, the example takes code and auto-creates the cumbersome code for you.
The idea is of course that this in the future would be internalized so users could simply use the new attributes and declaratively add dynamic parameters, in the same easy way static parameters work today.
In any respect, if you look at new ways to simplify dynamic parameters, for consistency and ease I‘d strongly recommend to use attributes to declare dynamic parameters as an alternative to using dynparam {} and low level .NET code.
dkattan commentedon Nov 17, 2023
I checked out your module at length actually when I was thinking through this. I think this approach is valid for simple hiding and showing of certain parameters, however I think a more straightforward way to do it would be to allow the ParameterAttribute.Hidden property accept a ScriptBlock that could be evaluated.
It also doesn't solve the problem of being able to dynamically populate ValidateSet, you'd still need traditional dynamic parameters for that. I put in a PR that would allow ValidateSet to take a ScriptBlock for creating these options but it was rejected: #17460
The team did say they were cool with getting rid of the RuntimeDefinedParameterDictionary but there hasn't been any movement on my PR with those changes: #20527
I understand that what I'm proposing is a relatively big change so I created an RFC for it a few weeks ago but it appears no one has looked at it:
PowerShell/PowerShell-RFC#361