Incremental Dynamic Parameter Bind

[dkattan]

Summary

1. Incremental Binding: As RuntimeDefinedParameter objects are written to the output in the dynamicparam block, they are immediately bound if an argument is available. This behavior differs from the current state, where all parameters are bound after the entire dynamicparam block has executed.

2. Variable Creation: When a RuntimeDefinedParameter is bound, a variable with the name of that parameter should be created in the dynamicparam block scope. This makes the bound value immediately available for subsequent logic in the dynamicparam block.

I already have a PR with the required code changes: PowerShell/PowerShell#20069
 

Example

For brevity, this example assumes a user-supplied New-Parameter function.

Function Get-EdgeUpdates
{
    param()
    dynamicparam
    {   
        $EdgeVersions = Invoke-RestMethod https://edgeupdates.microsoft.com/api/products
        # Emit a RuntimeDefinedParameter to the pipeline
        New-Parameter -Name Product -ValidValues $EdgeVersions.Product -Type ([string]) -Mandatory
        # $Product is immediately available for use
        if($Product)
        {
            $EdgeReleases = $EdgeVersions | ?{$_.Product -eq $Product} | select -Expand Releases # Beta,Stable,Dev,Canary
            New-Parameter -Name Platform -ValidValues ($EdgeReleases.Platform | select -Unique) -Type ([string]) -Mandatory # Windows,Linux,MacOS,Android
            if($Platform)
            {
                $EdgeReleases = $EdgeReleases | ?{$_.Platform -eq $Platform}                
                New-Parameter -Name Architecture -ValidValues ($EdgeReleases.Architecture | select -Unique) -Type ([string]) -Mandatory # x86,x64,arm64,universal
                if($Architecture)
                {
                    $EdgeReleases = $EdgeReleases | ?{$_.Architecture -eq $Architecture}                
                    New-Parameter -Name Version -ValidValues ($EdgeReleases.ProductVersion | select -Unique) -Type ([string]) -Mandatory    
                }
            }
        }
    }
    end
    {
    }
}

[dkattan]

@SydneyhSmith When do things like this get reviewed? I would love to be part of the conversation.

[SteveL-MSFT]

@JamesWTruher can you see if the Engine WG can review this?

[dkattan]

@JamesWTruher can you see if the Engine WG can review this?

I'd really love to be a part of the conversation with the working group. This is a non-breaking change, only net new functionality but the last time they reviewed it I was told to create an RFC so I did.

[dkattan]

@SteveL-MSFT Community call is tomorrow, still looking for feedback on this.

[IntegriComCalvin]

I would really really like to have this feature. So much easier to write and I have several use cases.

[homotechsual]

Would love to see this in PowerShell it would open up some interesting and more complex use cases not possible with the current implementation.

[gigacodedev]

I could definitely find use in this, seems useful for complex multi-site automation tasks that may have a varying set of environments.

[noaht8um]

+1. Have some existing modules that use dynamic parameters which would be streamlined with this. This would also open the door for less confusion when it comes to writing user-driven PowerShell modules (i.e. a helper module for technical folks that are not necessarily PowerShell savvy). This would be awesome.

[dszp]

+1 This would make it substantially easier to deal with situations such as the example, which likely has equal application in dealing with the mess of versions and channels of Office/Apps for Business/Enterprise besides Edge, in another Microsoft example.

This would be helpful in automating both with larger scripting toolsets and in adding better validation to more complex system admin and management scripts, so I support the change.

[immolate]

Anything Darren writes generally makes my life easier as one of his customers. Please consider the changes and merge so many, MANY people can benefit from his recommendations. Thanks.

[Dakota-LM]

I think this will add a lot of incentive for people to jump on dynamicparams. Currently, they don't seem to be as robust as one would assume for something called "dynamicparams".

[MWGMorningwood]

I think this will add a lot of incentive for people to jump on dynamicparams. Currently, they don't seem to be as robust as one would assume for something called "dynamicparams".

I 100% agree with this- it seems like Darren is the one trying to make the name true here

[etopple]

I’d love to see this pushed into production. Would be super helpful.

[dimitrirodis]

So, net new functionality with no breaking changes. Sounds like a win. What's the problem?

[jbbehar]

Agree with all the above comments - can this be prioritized for inclusion ASAP? This PR is already months old.

[JerBar]

This would be a huge game changer for sure.

[andrewqit]

Add one more to the list that needs this!

[tylernocwing]

I hope this gets implemented dkattan

[herringms]

Very needed for partners

[dlfoster311]

I think this would be a cool addition! It could make scripts way smarter by adapting on the fly as you define parameters.